Académique Documents
Professionnel Documents
Culture Documents
PENGGUNAAN KATA-LALUAN
Penggunaan kata laluan yang lemah punca pencerobohan dan berlakunya kebanyakkan
insiden keselamatan ICT
tiada kata-laluan
kata-laluan adalah sama dengan akaun pengguna
1
123
abc123
(akaun pengguna)123
(nama sistem)123
putrajaya
PRISMA juga menemui pelbagai peranti rangkaian (network devices) yang masih
mengekalkan kata-laluan asal yang dibekalkan oleh pembekal.
Selain dari tidak memerlukan pengetahuan teknikal yang tinggi terdapat pelbagai perisian
boleh digunakan bagi tujuan serangan bruteforce terhadap kata-laluan. Antara perisian
yang boleh digunakan adalah seperti berikut:
1. THC-Hydra
2. Brutus
Kedua-dua contoh perisian ini boleh digunakan untuk melakukan serangan bruteforce
terhadap kata-laluan secara jarak-jauh terhadap akaun pengguna sistem operasi berasaskan
Microsoft Windows ataupun UNIX. Ia juga boleh digunakan terhadap mekanisme
pengenalan dan pengesahan pengguna (authentication) yang terdapat pada laman web
Bagi mengatasi masalah ini, agensi adalah dinasihatkan untuk melaksanakan cadangan
pengukuhan berikut:
Pembangunan polisi dan juga program kesedaran perlu menekankan pengunaan kata-
laluan yang sukar seperti:
Kata-laluan yang digunakan pula perlu dihafal, bukan dicatatkan atau ditampal pada
tempat-tempat tertentu. Dengan itu, pengguna perlu memastikan kata-laluan tersebut juga
mudah diingat walaupun sukar untuk diteka.
Bagi tujuan menguatkuasakan polisi kata-laluan, latihan perlu diberikan secukupnya pada
penyelenggara sistem di agensi untuk mempelajari aspek pengukuhan di sistem operasi
ataupun aplikasi yang digunakan.
Selanjutnya, aplikasi yang dibangunkan sendiri ataupan oleh pembekal juga perlu dilengkapi
dengan modul bagi proses pengenalan dan pengesahan ini. Bagi aplikasi yang dibangunkan
oleh pembekal, terma-terma dan syarat seperti ini perlu dimasukan kedalam kontrak yang
bakal ditandatangani oleh kedua-dua pihak.
Sumber rujukan:
http://www.ictsecurity.gov.my/index.php?option=com_content&view=article&id=77:kata-
laluan-lemah-punca-pencerobohan&catid=58:security-expert&Itemid=101
XAMPP merupakan gabungan perisian yang mengandungi pelayan web Apache (dengan
modul PHP dan Perl) dan pangkalan data MySQL. Terdapat juga komponen-komponen lain
seperti pelayan mail SMTP dan POP 3 serta contoh-contoh web aplikasi yang menggunakan
teknologi PHP dan Perl. Tujuan utama perisian ini adalah untuk memudahkan pemasangan
komponen-komponen tersebut. Walau bagaimanapun, pemasangan dan konfigurasi asal
(default) bagi XAMPP ini mempunyai beberapa kelemahan yang terdedah kepada aktiviti
pencerobohan.
Kedua-dua kelemahan ini membenarkan kandungan pangkalan data dicapai dengan mudah
oleh penceroboh. Sebagai contoh, jika pihak agensi memasang perisian CMS Joomla!,
kandungan pangkalan data bagi perisian ini boleh dicapai dan diubah. Penceroboh boleh
mencapai kandungan akaun pengguna serta kata-laluan dan seterusnya menggunakannya
untuk mengubah kandungan laman web agensi (web defacement).
(1) Pemasangan dan konfigurasi asal membenarkan aplikasi phpMyAdmin dicapai dengan
contoh URL seperti berikut:
http://www.prisma-mampu.gov.my/phpmyadmin
Apabila URL ini dibuka menggunakan browser, keseluruhan kandungan pangkalan data
MySQL dapat dicapai dengan status admin atau "root":
Jika pihak agensi peka, sebenarnya terdapat notis amaran yang dipaparkan seperti berikut:
Pemasangan asal XAMPP juga terdedah kepada serangan pencarian maklumat awal
(information gathering) apabila terdapat pelbagai sambungan (link) kepada keseluruhan
aplikasi yang terdapat pada perisian ini. Contohnya, ia boleh dicapai dengan menggunakan
URL http://www.prisma-mampu.gov.my/xampp seperti berikut:
Sumber rujukan:
http://www.ictsecurity.gov.my/index.php?option=com_content&view=article&id=92:aspek-
keselamatan-xampp&catid=58:security-expert&Itemid=101
Bagi mengatasi masalah ini, XAMPP telah menyediakan sambungan terhadap Security
seperti berikut:
Sambungan bagi mengatasi kelemahan yang ada juga terdapat pada muka yang sama:
** Bagi mengukuhkan konfigurasi asal phpMyAdmin pula, agensi perlu untuk mengedit
fail config.inc.php dan menukarnya daripada konfigurasi asal:
$cfg['Servers'][$i]['auth_type'] = 'config';
$cfg['Servers'][$i]['auth_type'] = 'cookie';
Dengan konfigurasi ini, laman phpMyAdmin akan meminta kata-laluan apabila dicapai.
Laman phpMyAdmin bagi menyelenggara pangkalan data MySQL ini juga perlu
dihadkan capaiannya. Begitu juga dengan laman asal XAMPP. Sebagai contoh, hanya
penyelenggara sistem di rangkaian agensi sahaja perlu diberi kebenaran untuk mencapai
aplikasi web berikut:
http://www.prisma-mampu.gov.my/xampp
http://www.prisma-mampu.gov.my/phpmyadmin
Bagi tujuan ini, artikel "Pelayan Web Apache dan ACL" boleh dirujuk.
Bagi pengguna MySQL dan phpMyAdmin yang tidak menggunakan XAMPP, teknik di atas (*
dan **) juga boleh diaplikasikan.
Sumber Rujukan:
http://www.ictsecurity.gov.my/index.php?option=com_content&view=article&id=93:teknik
-pengukuhan-xampp&catid=58:security-expert&Itemid=101
Bagi mengatasi kelemahan directory listing, tuan/puan adalah disarankan untuk disable
fungsi directory listing pada server web agensi tuan/puan
Sebarang insiden keselamatan ICT perlulah dilaporkan kepada pihak GCERT merujuk kepada
Pekeliling Am Bil.1 Tahun 2001 - Mekanisma Pelaporan Insiden Keselamatan Teknologi
Maklumat dan Komunikasi (ICT) (http://gcert.mampu.gov.my ).
Panduan untuk disable directory listing boleh di muat turun di ruangan Muat Turun
(hyperlink perkataan yang diboldkan “Muat Turun” dengan url berikut:
http://gcert.mampu.gov.my/index.php?option=com_content&task=view&id=20&Itemid=47
untuk makluman: maklumat bahagian yang ditandakan ini tidak perlu di masukkan ke dalam portal )
Sumber Rujukan:
http://gcert.mampu.gov.my/index.php?option=com_content&task=view&id=94&Itemid=98
- ACL -
Kawalan capaian atau ACL ini perlu digunakan untuk menghadkan capaian terhadap
sumber-sumber tertentu pada laman web. Sebagai contoh, pengunaan Joomla! Content
Management System (CMS) mempunyai laman yang dikhaskan untuk penyelengara sistem.
Begitu juga bagi pengguna perisian phpMyAdmin bagi menyelenggara pangkalan data jenis
MySQL. Kedua-dua aplikasi ini pada umumnya boleh dicapai seperti contoh berikut:
Joomla! - http://www.prisma-mampu.gov.my/administrator/
phpMyAdmin - http://www.prisma-mampu.gov.my/phpmyadmin/
Kedua-dua contoh sumber laman web agensi ini perlu untuk dihadkan capaiannya bagi
meminimumkan ancaman siber yang berleluasa pada masa ini. Antara ancaman yang
berlaku adalah seperti percubaan untuk mengeksploitasi kelemahan aplikasi dan juga
meneka pengunaan kata-laluan yang lemah.
Dengan menggunakan pelayan web Apache ini, sumber tersebut boleh dihadkan
capaiannya dengan membenarkan IP-IP tertentu sahaja.
Bagaimana?
Berikut merupakan direktif bagi konfigurasi pelayan web Apache yang boleh digunakan
untuk menghadkan capaian terhadap direktori "/administrator":
Order Deny,Allow
Allow from 10.1.1.0/255.255.255.0
Deny from all
</Location >
Dengan mengunakan direktif di atas, hanya satu blok IP dari 10.1.1.x sahaja yang boleh
mencapai direktori administrator tersebut.
Sumber Rujukan:
http://www.ictsecurity.gov.my/index.php?option=com_content&view=article&id=81:pelay
an-web-apache-dan-acl&catid=58:security-expert&Itemid=101
Security is a vast and fast-moving subject. No one document can cover it all. This checklist is
designed to help you with only two things.
Not all security techniques are appropriate for both versions of Joomla. Where a technique only
applies to one version, an image is added. For example:
Register Globals
Extensions
To take full advantage of new security features, ensure that all third party
extensions are Joomla! 1.5 native.
Download extensions from trusted sites, and compare the file's MD5 hash to detect
download errors. This suggestions applies to both versions, so no compatibility image is
used.
Read Me First!
Due to the variety and complexity of modern web systems, security issues can't be
resolved with simple, one-size-fits-all solutions. You, or someone you trust, must learn
enough about your server infrastructure to make valid security decisions.
To secure your web site, you must gain real experience (some of which will be bitter), or
get experienced help from others.
The Security Forums are filled with "Help! I've been hacked" posts by people who did
NOT follow standard security practices (this author included). If you decided to study
documents such as this before your site is attacked, congratulation, you're already
above the herd.
The following checklist may seem intimidating, but you don't have to deal with all of it at
once. As you become familiar with tools of modern Open Source Web development,
such as GNU/Linux, Apache, MySQL, SQL, PHP, HTTP, CSS, XML, RSS, TCP/IP, FTP,
Subversion, JavaScript, Joomla!, you'll add refinements to your set of security tactics.
All complex, dynamic, and open systems require powerful error checking and recovery
methods. Web sites are no different. Strong security is a moving target. Today's expert
might be tomorrow's victim. Welcome to the game...
Getting Started
2. Do you have the time and resources to respond to the flow of emerging Internet
security issues? The Top 10 Stupidest Administrator Tricks is a comic/tragic look at what
can go wrong. Don't learn these tricks the hard way! Depending on your recent
experience, reading the Stupidest Tricks will either make you laugh or cry.
Given the complexity of web servers, new vulnerabilities and conflicts are discovered all
the time. To stay in the loop, subscribe to Joomla Security Announcements.
There is also the RSS feed right from the Joomla Security Strike Team which will keep you up to
date on every core vulnerability!
The most helpful posts in the Joomla! Security Forum are converted into Security and
Performance FAQs. Many of the items on this list are explained in much greater detail in
the FAQs.
Hunt down the many nuggets of wisdom found in the Joomla! Forums.
Probably no decision is more critical to site security than the choice of hosts and servers.
However, due to the wide variety of hosting options and configurations, it's not possible
to provide a complete list for all situations. Check this unbiased list of recommended
hosts who fully meet the security requirements of a typical Joomla site. (FAQ)
If you are on a tight budget and your site does not process highly confidential data, you
can probably get by with a shared server, but you must understand the unavoidable
risks. Most of the tips listed below are appropriate for securing sites on shared server
environments.
For a real eye-opener, read this report on thousands of sites that allowed Google to
index the results of phpinfo(). Don't make this mistake on your site! The report includes
alarming statistics on the percentage of site that use depreciated settings such as
register_globals ON or that don't have open_basedir set at all: By the way, if phpini and
register_globals are unfamiliar terms you are probably not ready to securely manage
your own site.
Develop and test your site on a local machine first. Installing Joomla locally is not as hard
as it may sound, and the exercise will greatly boost your confidence.
Use an IDE
Be able to roll back to an earlier version of your site using a modern version control
system, such as CVS or Subversion.
Check out the Joomla! community's list of popular Developer Software and Tools.
Configuring Joomla!
To avoid braking your site, search the forums for reports of incompatible extensions
before upgrading to a new version of Joomla.
Upgrade to the latest stable version of Joomla! as soon as possible.
Download Joomla! from official sites only, such as JoomlaCode.org, and check the MD5
hash.
Use Joomla Diagnostics to ensure that all files were installed correctly.
Change the user name of the default admin user. This simple step greatly increases the
security of this critical account by modifying one of the two variables attackers can use
to gain admin access. The admin password is the other variable. Change it early and
often.
Once your site is configured and stable, write-protect critical directories and files by
changing directory permissions to 755, and file permissions to 644. There is a feature in
Site --> Global Configuration --> Server to set all folder and file permissions at once. Test
third party extensions afterwards, and carefully review the code of any extension that
has trouble with such settings. Note: Depending on your server's permissions, you may
need to temporarily reset to more open permissions when installing more extensions
with the Joomla! installer.
Remove all design templates not needed by your site. Never put security logic into
template files.
Delete leftover files. The installation process will require you to delete the installation
directory and all its contents. Do this; do not simply rename it. If you upload files to your
site as compressed archives (xxxx.zip for example), don't forget to remove the
compressed file. In general, do not leave any unneeded files (compressed or otherwise)
on a public server.
Configuring Apache
Block typical exploit attempts with local Apache .htaccess files. This option is not
enabled on all servers. Check with your host if you run into problems. Using .htaccess,
you can password protect sensitive directories, such as administrator, restrict access to
sensitive directories by IP Address, and depending on your server's configuration, you
may be able to increase security by switching from PHP4 to PHP5.
Consider following the "Least Privilege" principle for running PHP using tools such as
PHPsuExec, php_suexec or suPHP. (Note: These are advanced methods that require
agreement and coordination with your hosting provider. Such options are enabled or
disabled on a server-wide bases, and are not individually adjustable on shared servers.)
Configure Apache mod_security and mod_rewrite filters to block PHP attacks. See
Google search for mod_security and Google search for mod_rewrite. (Note: These are
advanced methods that usually require agreement and coordination with your hosting
provider. Such options are enabled or disabled on a server-wide bases, and are not
individually adjustable on shared servers.)
Configuring MySQL
Be sure MySQL accounts are set with limited access. The initial install of MySQL is
insecure and careful configuration is required. (See the MySQL Manuals) Note: This item
applies only to those administering their own servers, such as dedicated servers. Users
of shared servers are dependent on their hosting provider to set proper database
security.)
Configuring PHP
Understand how to work with the php.ini file, and how PHP configurations are
controlled. Study the Official List of php.ini Directives at http://www.php.net, and the
well-documented default php.ini file included with every PHP install. Here is the latest
default php.ini file on the official PHP site.
Use PHP5
Currently, both PHP4 and PHP5 are maintained, and both are often available on servers.
Before PHP4 becomes obsolete, upgrade your custom scripts to PHP5. Don't worry
about core Joomla code; all current versions are PHP5 compatible. (See PHP News)
On shared servers you can't edit the main php.ini file, but you may be able to add
custom, local php.ini files. If so, you'll need to copy the php.ini files to every sub-
directory that requires custom settings. Luckily a set of scripts at B & T Scripts and Tips
can do the hard work for you.
There are a few important things to keep in mind.
1. Local php.ini files only have an effect if your server is configured to use them. This
2. Local php.ini files only effect .php files that are located within the same directory (or
included() or required() from those files). This means that there are normally only two
Joomla! directories in which you would want to place a php.ini file. They are your
http_root(your actual directory name may vary), which is where Joomla's Front-end
index.php file is located, and the Joomla! administrator directory, which is where the
Back-end administrator index.php file is located. Other directories that don't have files
called via the Web do not need local php.ini files.
3. If you have a php.ini file in every directory, some script probably did this for you. If you
didn't intend it to happen, you probably should root them out, but given #2 above, you
probably only have to panic about the php.ini files in http_root and the administrator
directories.
Use disable_functions to disable dangerous PHP functions that are not needed by your
site. Here is a typical setup for a Joomla! site:
disable_functions = show_source, system, shell_exec, passthru, exec, phpinfo, popen,
proc_open
open_basedir should be enabled and correctly configured. This directive limits the files
that can be opened by PHP to the specified directory-tree. This directive is NOT affected
by whether Safe Mode is ON or OFF.
The restriction specified with open_basedir is a prefix, not a directory name. This means
that open_basedir = /dir/incl allows access to /dir/include and /dir/incls if they exist. To
restrict access to only the specified directory, end with a slash. For more information,
open_basedir = /home/users/you/public_html
Adjust magic_quotes_gpc
Adjust the magic_quotes_gpc directive as needed for your site. The recommended
setting for Joomla! 1.0.x is ON to protect against poorly-written third-party extensions.
The safest method is to turn magic_quotes_gpc off and avoid all poorly-written
extensions, period.
Joomla! 1.5 ignores this setting and works fine either way. For more information, see
PHP Manual, Chapter 31. Magic Quotes.
magic_quotes_gpc = 1
Avoid the use of PHP safe_mode. This is a valid but incomplete solution to a deeper
problem and provides a false sense of security. See the official PHP site for an
explanation of this issue.
safe_mode = 0
Automatically registering global variables was probably one of the dumbest decisions
the developers of PHP made. This directive determines whether or not to register the
EGPCS (Environment, GET, POST, Cookie, Server) variables as global variables where
they become immediately available to all PHP scripts, and where they can easily
overwrite your own variable if you're not careful. Luckily, the PHP developers long since
realized the mistake and have depreciated this 'feature'.
If your site is on a shared server with a hosting provider that insists register_globals
must be on, you should be very worried. Although you can often turn register_globals
register_globals = 0
Don't use PHP allow_url_fopen. This option enables the URL-aware fopen wrappers that
enable accessing URL object like files. Default wrappers are provided for the access of
remote files using the ftp or http protocol, some extensions like zlib may register
additional wrappers. Note: This can only be set in php.ini due to security reasons.
allow_url_fopen = 0
Extending Joomla!
Before installing new extensions, always do a quick backup of your site's files and
database. This follows a very basic and key principle:
Thou shalt at all times be able to return your site to a previous working state if
something goes wrong.
Therefore, it's smart to set up a simple and fast backup script to automated this task. If
you don't setup a simple process in advance, you'll be sorely tempted at some point to
do a quick upgrade without backing. This very understandable tendency is, however,
one of the chief causes of premature developer death.
Most security vulnerabilities are caused by third party extensions. Before installing
The fully qualified and official definition of a "trusted site" is one that YOU trust.
Third party extensions come in all flavors of quality and age. Although Joomla! coding
standards exist, third party developers are not required to follow them. Extensions
listed on the official Joomla! site are not reviewed for compliance, however if verified
vulnerabilities are reported, they will be removed from the list until they are fixed.
Test all extensions on a development site before installing on a production site. Then
test on the production site. Don't forget the check the logs for runtime errors and
warnings.
Remove all unused extensions and double check that related folders and files were
actually removed by uninstall scripts. Note that during uninstall, many third party
extensions will leave related files on your site, and related database tables complete
with data. This is either a feature or a bug depending on your point of view. Any files left
on your server remain accessible from the Web via direct URLs, such as
http://example.com/modules/bad_module.
Joomla is (and dispite disinformation campaigns, always has been) a GNU GPL project.
Of course, code that is not distributed to others is exempt from GNU GPL distribution
requirements. Thus you can encrypt Joomla-related code your own servers providing
you do not share it with others.
For maximum security, avoid a shared server on which you don't know or can't trust all
the other users or their code quality.
SSL servers are currently the only way to securely process confidential transactions and
secure user authentication. SSL works by encrypting all HTTP communications between
the Web server and Web clients. Thus, even if a transmission is intercepted, it can not
be read.
Joomla! 1.0.x does not allow you to assign an SSL server to individual sub-directories.
Search the forums for "Tommy Hack" for one way to deal with this. Joomla! 1.5 has
greatly improved SSL options.
Joomla Downloads
Change passwords regularly and keep them unique. Use a random combination of
letters, numbers, or symbols and avoid using single names or words found in a
dictionary. Never use the names of your relatives, pets, etc. Search the forums for a
script supplied by Wizzie that automatically changes passwords. This is a great tool for
administrators or multiple sites.
Most users may not need more than three levels of passwords and webmasters no more
than five. Each level must be completely unrelated to the others in terms of which
usernames and passwords are used.
Never rely on others' backups. Take responsibility for your backup procedures. Many
ISPs state in their contract that you can not rely solely on their backups.
VPS and dedicated server users can run TripWire or SAMHAIN. These applications
provide exhaustive file checking and reporting functionality, and can be installed in a
stealthy manner to help protect themselves in the event of a serious infiltration. (Note:
Users of shared servers can not use this technique.)
Google search
Regularly check raw logs for suspicious activity. Don't rely on summaries and graphs.
Google Search
Use tools such as Paros Proxy for conducting automated SQL Injection tests against your
PHP applications.
Google Search
Wikipedia Article
Exploit Checking
There is not a single tool that can protect your site. If there were, it would be so heavily
targeted that it would probably become a liability.
Every now and then hire a professional Joomla! security consultant to review your
configurations. Do you remember the adage, "Anyone who acts as their own lawyer has
a fool for a client." The same goes for Web development. Don't expect to catch all of
your own security mistakes.
Site Recovery
3. Have a tested plan for how you will recover when your site's been compromised.
Your Turn...
Sumber Rujukan:
http://developer.joomla.org/security/articles-tutorials/260-joomla-administratots-security-
checklist.html