Linus Torvalds made a Mother’s Day gift to the world in the form of the 3.10-rc1 kernel prepatch. With this release, the merge window for the 3.10 development cycle has closed, so we know which features to expect this time around.
The feature that has arguably drawn the most attention is one that will probably not have a huge effect for most users: the addition of (nearly) full dynamic tick support. The periodic “timer tick” is an interrupt that is delivered every 1-10ms while the CPU is busy; it is the kernel’s cue to perform various important housekeeping tasks. It is also a distraction from the work the user really wants done and it can slow down the system’s response time slightly. That slowdown is especially irksome to some high-performance computing and realtime users.
In 3.10, the kernel can turn off the timer tick in some situations, but most users will notice no performance difference. The suppression of the timer tick should happen more widely in future kernel releases; meanwhile it is an interesting bit of work and a significant step forward for the core kernel. Congratulations are due to Frederic Weisbecker, who did the bulk of the heavy lifting in this effort.
Other significant changes include a number of tracing improvements, a mechanism by which user space can be notified when the system is under memory pressure, and the bcache storage caching layer. See the Linux Weather Forecast page for a more complete list.
In the end, nearly 12,000 independent changes were pulled into the mainline during the twelve-day merge window. That makes this merge window the busiest in kernel development history and suggests that the final 3.10 release (due in early July) will be the largest kernel development cycle ever. The kernel and the community that develops it continue to grow.
[This article is frequently updated and expanded at it's originating link above. It is gradually being broken apart into separate articles because the Google language translator doesn't translate all the text of large pages.]
Related pages that were previously part of this one:
Hopefullly, this detailed step-by-step procedure will help focus on the tasks and avoid panic.
The concepts apply to any server even though it is Linux, Apache, and cPanel methods that are described in detail.
The steps are in order of priority if the evidence you’ve found so far hasn’t already given you a clear idea what things to focus on first.
The reason these procedures are described in so much detail is so that people who have never done them don’t have to go hunting around the web for specifics. If you already know the specifics, you’ll see that the steps are much less complicated than they look at first glance, and you can skip the long explanations.
If you just start at step 1, focus, and dive in, what you learn now will help you manage your site with a lot more confidence in the future. These are all useful things to know how to do. You might even wind up feeling like an expert.
What not to do
Don’t just repair the damaged files and hope this experience doesn’t happen again. That is not enough.
Nobody is ever supposed to be able to add, delete, or change files in your website without your permission. It should never happen, and it usually doesn’t. Most websites don’t get hacked. If yours did, there is something wrong with it, or with the server, or with the webhost, or with the security on your PC. You have to figure out how this happened so you can prevent it from happening again.
Ok, let’s get started… The checkboxes don’t do anything. You can check them to help keep your place as you go.
1) Log into cPanel
Most webhosts provide some kind of control panel such as cPanel or Plesk where you can manage your website’s configuration and files. One reason for logging in now is to check for unauthorized logins as described below. The more important reason is to make sure you know how to do it, because several of the later steps are done in control panel.
If you’ve never logged into your control panel before now, go to the home page of your webhost’s website and look for a customer login box. If there isn’t one, look for a FAQ page where they might describe how to access your control panel. If you still find nothing, file a support ticket and ask them.
In cPanel (and possibly in Plesk), the line that says “Last login from:” should always be your IP address from the last time you logged in. If it isn’t, write it down.
If you don’t know your IP address, it appears to be 79.231.123.41, but that could be incorrect if you are viewing an old copy of this page from your browser cache or a search engine cache. You can find your IP address in Windows XP by either of these two methods (you must be connected to the internet at the time you do this):
Click on the internet connection icon in your system tray (lower right of screen) . In the dialog box that opens, click the Details tab, and then read the line that says Client IP address.
Open a Command Prompt and run the ipconfig program: start > Run > cmd
Type: ipconfig
Read the line that says IP Address
Type: exit
With high-speed (broadband, DSL, cable) internet service, your IP is always the same. With dial-up, it’s different each time you log on.
If someone was able to log in to your control panel (like you do), they have your userID, password, and all the same access to your site that you have. They can probably also get FTP access, which is what they are more likely to use than cPanel. However, before you assume the worst, an unfamiliar IP could be legitimate if your site is at a webhosting company and you recently submitted a support ticket. A technician might have logged into your account while investigating.
The three pieces of information you should keep from this step are:
How to log in to your control panel.
Your legitimate IP address, so you can recognize IP addresses that are not yours in places where only yours should be.
Suspicious IP addresses you find reported in cPanel.
Leave cPanel open for the next two steps.
2) Enable log archiving in cPanel
Your website access logs keep detailed records of who connects to your site by HTTP (normal visitors) and by FTP (file transfers such as when you publish pages). By default, those logs are deleted every day after the stats run (Webalizer, AWStats, …). Log archiving forces the logs to be saved. If archiving was already on, the attack is most likely recorded, which will be useful. If it was off, the data is lost unless the daily stats run hasn’t been done yet, but subsequent similar attacks, which are likely, will be logged.
Go to cPanel > Raw Log Manager (the name varies in different cPanel versions).
Check the “Archive Logs…” box.
Uncheck the “Remove the previous month’s archived logs…” box.
Click Save
3) Take your website offline
If your pages have become infected with viruses that will attack your site visitors, which is usually the case, you should protect your visitors, and your reputation, by taking your site offline, which involves adding a few lines to your .htaccess and optionally uploading a file. If you do this right away, you might avoid getting the “This site may harm your computer” warning in Google search results and a similar warning at Yahoo.
Are you hesitant to take your site offline? Consider this: a visitor who finds your site down will hardly notice the incident and will (or at least might) come back later. A visitor who gets attacked by a virus from your site will develop a strong memory of the incident and probably not come back, ever.
In addition, it is possible that a script with a security hole was the reason the site got hacked. As long as that script is publicly accessible, the site remains vulnerable, which means it could get hacked again even while you’re trying to repair it.
Lastly, it is possible the attacker installed a backdoor script to let themselves back into the site. Closing the site at least has a chance of locking them out and making it impossible for them to use the backdoor, giving you time to find and delete it.
4) Notify your web hosting company
File a support ticket.
Tell them what has happened. Give them as much detail as you can about the evidence that the site is compromised.
If you have some idea when it happened, or when you first noticed it, tell them.
If you found an unknown IP address in cPanel, report it.
Give them a secondary email address that is not at your website so your host can still contact you if your site goes down or if the hacker is reading or deleting your website email.
Some webhosts will be willing to help you investigate and clean the site. Others won’t, but it doesn’t hurt to ask if they can help or give advice.
If you’re on shared hosting, it is possible that the host is aware of other sites on your server that are affected. They probably won’t publicize it and might not even tell you, but your report will help them, even if they don’t admit it.
Also, only your webhost can clean up files outside your webspace that might have been affected.
5) All site administrators do antivirus, antispyware scans on their PCs
It is a new development in 2009 that the #1 cause of website hacking is the webmaster’s personal computer being infected by malware that steals FTP login information and sends it to remote computers which then inject the victim website’s pages with JavaScript or hidden iframes pointing to malicious websites such as gumblar.cn, martuz.cn, and a growing list of others.
As long as the webmaster’s PC is infected, changing the password is no use. The new one gets stolen, too.
6) Change all passwords: cPanel, FTP, databases, email
After the administrator PCs are free of viruses and spyware, change all the website passwords that you use for control panel, FTP, database connections, email, everything. Use strong passwords. If you have been using a single password for more than one purpose, take this opportunity to make every password different. The linked article explains why this is important.
a) If the FrontPage Extensions are installed on the site, change your FrontPage password first:
Open your local copy of your site in FrontPage
Click the Remote Web Site tab and log in
Click Open your Remote Web site in FrontPage (this will open a new copy of FrontPage with your remote site in it)
Click Tools > Server > Change Password and follow the instructions. Whenever you get a password prompt during this procedure, it wants the old one. It doesn’t want the new one until it asks for it.
b) Log in to your webhosting account and change your cPanel / FTP passwords there
In cPanel, look for a “Change Password” icon or link. If you find none, your webhost might provide a separate login location for making password changes, so search their FAQ, forum, or ask customer support.
If you have scripts that use your cPanel userID/password to open database connections, the password change will cause those scripts to stop working, and you will get connection failure or “Could not connect” errors:
If the connection data is hard-coded into the scipts, go through the scripts and change the password in all of them.
If your scripts read the connection data from an include (or other) file, change it in that file.
Since you’re editing the files anyway, a better and more permanent solution is to stop using your cPanel userID/password, create a different user/password just for database connections, put the connection data in one protected include file, and have all your scripts read the data from that file. The procedure for making that change is described below.
c) Change the passwords you use for database connections
If your scripts connect to your databases as a user that is not your cPanel userID, the password change will not break your scripts. However, the hacker could have read the connection data for all your MySQL users from your files, so change all those passwords, too:
Go to cPanel > MySQL® Databases > Current Users.
In the list, find the user you want to modify. In shared hosting (and maybe in other environments, too), the username is prefixed with YourUserID_.
In Username: enter the name of the user, but do not enter the prefix or the underscore. Enter only the part after the underscore. If the user is userID_example, then you enter example.
In Password: enter the new password.
Click Create User.
The confirmation screen will tell you that the user was created with the new password.
When you return to the MySQL Account Maintenance screen, you’ll see that you have not really added a user, but only replaced the old one’s password, and that this user still has the same privileges in the same databases that it had previously. You will also see that cPanel has automatically added the userID_ prefix to the username.
Now change all your scripts to use the new passwords. See the bullet points in section b) above.
d) Change the passwords for all your email accounts
Go to: cPanel > Mail > Add/Remove/Manage Accounts.
Set a new password for each account.
If you access your email with a POP or IMAP email client such as Microsoft Outlook, change its configuration settings so it knows the correct new password for each account.
7) Upgrade all third party scripts to latest versions
Make a list of all the scripts you use. For each, if you are not using the latest version, upgrade now.
Follow links in the table below to find latest version information for some common scripts, and to view the latest security advisories at Secunia.com. The Secunia page often lists vulnerabilities found in plug-ins or add-ons. Check those, too. If there is a recent security advisory for a script you use that is outdated, there is a good chance you’ve found the reason your site was hacked.
Just keeping up to date has not always been enough to keep osCommerce secure. The osCommerce forum has additional security advice for Version 2.x and Version 3.x
8) Examine your own PHP or ASP.NET code for security holes
The “What is a website hack?” article (top of this page) has more information about the following three most common exploits of custom code, and some others:
Remote File Inclusion (RFI), Local File Inclusion (LFI)
can be tricked into fetching a malicious script from a remote server and running it as part of the currently executing script if the value of $variable came from an HTTP query string or other user-supplied input and if the value supplied is a URL (web address) rather than the value that the programmer expected.
They can be tricked into divulging the contents of password or other sensitive files if the supplied value of $variable is a local file path on the server.
SQL Injection
When an HTTP query string, or any other data from the outside such as input to a search box, is used in the building of an SQL database command string, maliciously crafted input can corrupt the SQL command, causing it to inject content into database tables or list the contents of the database (such as user names and passwords) on the output page. A widespread attack that used SQL injection was called ASPROX.
If you suspect that a script you wrote yourself might be the security weakness, it is safest to stop using that script until you can examine it carefully. After making a local copy for yourself, delete the script from the server. Removing the links to it isn’t enough. As long as the script is on the server, anyone who already knows its name can still access and exploit it. If you leave it on the server, at least rename it.
9) Find and repair all the malicious changes that were made
Now that you have discovered where the security weakness was, and fixed it, it is now safe to repair your website’s content, because the attackers won’t be able to damage it again.
As described in the “What is a website hack?” article (top of this page), after someone has gained access to your site, they can change anything they want and can do an extraordinary amount of damage. In order of most to least common:
Alter .html, .php, and other text web pages, usually to inject iframes, JavaScript, links, PHP, or other malicious code.
Modify database tables, usually to inject the same types of content listed above, so it will appear on your pages.
Add new files.
Add executable programs to let the attackers “manage” your website files remotely, grant them access even after you clean up (back doors), send spam, connect to IRC servers for botnet communications, mass-attack other websites, etc.
Subvert the operating system, putting the entire server under the control of a remote operator.
However, they rarely do all those things because a server so massively compromised would be quickly noticed, and they don’t want that. Usually, they do the first or second item and possibly the third, meaning that you will probably have to clean up malicious changes in your website files or database tables, and look for new files that shouldn’t be there.
Two “clean sweep” shortcuts: replace entire website from known-good backups
Steps 9a) to 9d) describe ways to locate and repair files that have been maliciously altered, which can be a time-consuming and painstaking chore, especially if you’re not comfortable working with HTML code.
In some cases, it can save time to simply replace everything that might have been damaged with fresh copies that you know are clean. However, doing this destroys the evidence you might need for determining how the attack occurred and how to prevent it happening again. Therefore, before doing this, you should already have a clear idea why the attack succeeded, or should make a copy of the hacked site so you can study it later:
Less drastic – replace contents of public_html: If you are thoroughly familiar with what is in your public_html folder and you are certain this method won’t destroy irreplaceable files, you can use cPanel > File Manager or FTP to delete all the files and folders inside /public_html (but don’t delete the public_html folder itself) and republish the entire site from a known-good backup.It will still be a good idea to look for damaged files or malicious new ones in your root directory (/) and its other subdirectories other than public_html.
More drastic – reprovision: To really start fresh at a shared host, you can ask the host to “reprovision” your account, to recreate it as though it is brand new. You lose your historical logs and stats and must build the site up from nothing. I recommend against this unless all other options have failed.
If you have published your site from known-good backups, you can skip a ton of trouble and go to Step 10)!
9a) Get a complete listing of all the files in your website
These sections (9abc) describe three ways to view a list of all the files in your website: shell command (cron), FTP, and cPanel File Manager.
Linux “cron” allows you to run a shell command that emails to you a complete listing of all the files in your site, showing for each the name, timestamp, size, owner, and all the permissions settings. This is by far the best method. It is described fully in a separate article that also explains Linux file and folder permissions.
How to use the directory listing:
It is ideal if you have a similar list that you made previously when the site was clean. You can compare the two to find files that have changed size, files whose timestamps or permissions are not what they should be, and new files that shouldn’t be there.
If you don’t have a known-good list to compare against, you can still review the new list for files that seem out of place or have wrong ownership or permissions. This will be discussed below.
9b) Examine your site’s files in cPanel > File Manager
FileManager allows you to easily review filenames and permissions, but it doesn’t show any other information about the files, and navigating up and down the directory tree is a tedious process. File and folder permissions are shown numerically. The article linked above at “Get a complete listing” describes how to translate between numeric “755″ and “rwx” notation.
9c) Examine your site’s files using FTP
In an FTP view of your website, the folders and files look like what you are used to in Windows Explorer, with a navigational directory tree pane on the left and a folder contents pane on the right. FTP view is easy to navigate, and it allows sorting on the Date Modified column to easily spot recently changed files. If you are unfamiliar with viewing your site by FTP, this article describes how to use Windows Explorer for that, and it has a link to a free Firefox plugin (FireFTP) that does it better.
9d) What to look for in the list of files
Pages with modified dates more recent than you last saved the page yourself. Inspect each modified page to see if code has been added to it. Malicious changes to your displayable website pages often take the form of invisible iframes or “obfuscated” JavaScript. A separate article, what to do when Google flags your website with a “This site may harm your computer” warning, describes how to locate and identify malicious iframes and JavaScript, with examples. It also describes how the domain name referenced in the iframe can help discover the method by which your website was hacked.If malicious JavaScript or iframes were added to your pages, the intent of the attack was probably to launch browser exploits against your site’s visitors.
New files with obviously suspicious names. Some hacks install files with names like hacked.html or vulnerable.php, etc. Others might have nonsensical names or names consisting of random character strings. Some might be in locations that make them suspicious, like a .php file in your /images folder. If you find a file that was definitely installed by the attack, search for other files that have almost the exact same timestamp.
Files you don’t recognize. Determine whether each one is malicious or not. You can examine plain text PHP (.php) or Perl (.pl) scripts in a text editor.Unfortunately, you cannot simply delete all the files that aren’t yours. Some are required system files that you just never noticed before. When in doubt, do a web search on the filename or post a question in a forum. Research the names of unfamiliar CGI programs, since they cannot be examined visually.
If an exploit modified files on your server but didn’t affect your displayable pages, it suggests that your site visitors weren’t the target of the attack. Instead, it might have been trying to turn your site into a spam emailer or into a robot crawler to attack other sites, or to install on your site a library of malicious scripts or other content to be called by injected iframes or RFI attacks on other websites.
Check your root directory (“/”) and its subdirectories for malicious or altered files. Even if you delete the contents of your public_html and republish the site from scratch, that doesn’t overwrite your folders above public_html, so you must check those manually.
9e) Search your website files for suspicious changes
This PHP script can help search your website for suspicious filenames, for suspicious code, and for other suspicious text.
10) Check that your file and folder permissions are secure
Using the complete file list you made, make sure file and folder permissions are what they should be. Although your complete file list is a text file, the search isn’t too difficult. You can search for suspicious “world-writable” 777 folder permissions by searching for the equivalent “rwxrwxrwx” in the text. World-writable 666 file permissions appear in the text as “rw-rw-rw-”.
Common correct permissions for world-readable (but not world-writable) folders are 755 (rwxr-xr-x), and common permissions for world-readable files are 644 (rw-r–r–). Those are what you should mostly expect to see.
There are only two situations where world needs write access (777 / 666), and both only apply if your server is configured with PHP as an Apache module:
A file needs 666 permissions if PHP needs to a) open the file and write data into it, or b) copy another file to the directory entry currently occupied by this file.
A folder needs 777 permissions if PHP needs to a) dynamically create new files in it, or b) delete existing files from it. However, if PHP only needs to open and modify the contents of an existing file or even copy another file to the directory slot occupied by an existing file, the folder does not need 777 permissions. It is only necessary that the destination file have 666 permissions. That is counterintuitive because you would think that copying a file involves deleting the existing file and putting the new file where it was, but that is not how Linux views it. It only considers it a change in the file’s content, not a change to the directory, so the directory can remain read-only. This is important because there may be some files that PHP only needs to create once, during a program’s initial installation when it’s setting up its data files. After that, it’s possible PHP can do everything it needs with the file set to 666 but the directory locked back down to read-only 755. That is much better because although that one file remains potentially vulnerable to modification, a hacker cannot put new malicious files in a 755 directory.
If you find world-writable permissions on a file or folder, consider it potentially suspicious because those are areas the hacker could have accessed most easily:
Check the contents of 777 folders to ensure they don’t contain malicious new files.
Check the contents of 666 files to ensure they don’t contain new malicious code.
If you can’t think of a good reason why the loose permissions are necessary (does PHP really need to make the changes those permissions allow?), try tightening them to 755 / 644.
Even if you do know why the loose permissions are necessary, try to think of a way to make those permissions unnecessary.
11) Change all your passwords again
In case someone was “watching” inside your site while you did it the first time, do it again now that you know the site is clean.
12) Try to identify the IP address that attacked you
This is not to hunt down the attacker, which is usually pointless (most are robots, and there are millions of them). Rather, the IP address helps find other important information about the attack.
If you can identify their IP address, you will be able to search all your logs for all the places where that IP address appears. That will help identify what weak part of your site was attacked, how it was attacked, and what malicious actions were performed.
Stats programs like Analog, Webalizer, or AWStats won’t be much help because they generate aggregated summary statistics. You need the details about individual page requests.
cPanel > Web/FTP Stats > Latest Visitors is useful and easy. It’s a good place to go when you first discover the problem, but it’s only a start. The raw log text files are a better source of information.
a) If you have never used your site’s raw access logs before, get a program to unzip .gz files:
Your website’s raw access logs are stored and sent to you as gzipped files. One program that will easily extract .gz files is 7-Zip. It is a command line utility that you run from a “Command Prompt” (aka “DOS box”).
b) Get your logs from cPanel > Raw Log Manager
The log file location in Plesk has a similar name. If you don’t have cPanel, Plesk, or a comparable control panel, you can usually get the logs by FTP, usually from a folder outside public_html, with “logs” or “access logs” in its name. Some shared webhosts don’t provide access logs, or they charge an extra fee for them.
Go to cPanel > Raw Log Manager. If you don’t see a log file there, try cPanel > Raw Access Logs. That is a holding file where your data is stored until the server does its daily statistics processing, after which the data file is transferred to Raw Log Manager.
Click the name of the file you want to download.
At the Open or Save prompt, click Save. Use a descriptive filename. Save the file to a folder that will be easy to navigate to in a Command Prompt. C:\TEMP works well.
Open a Command Prompt:
Start > All Programs > Accessories > Command Prompt, or
Start > Run > cmd.exe
Go to the folder where you saved the .gz file: cd \TEMP
Type the command line to extract the .gz file: 7za.exe x filename.gz
You should get a report that says “Everything is Ok”.
I usually delete the .gz file and rename the output file to .log.
The unzipped log files can be extremely large. In Windows, WordPad can handle up to about 12MB. For easier viewing, set the font to a monospaced font like Courier New, with word wrap Off. Notepad++ can handle files of 100MB or more. In Linux, the gedit editor capacity seems almost unlimited.
If you are comfortable using Microsoft Access, the Webstats.mdb database has tables into which you can import your log files.
The HTTP log will also import into Excel, but you will need to tweak the text import wizard settings to get the fields into their columns properly.
Go through the logs carefully, looking for suspicious activity in the days before the attack occurred, and keep monitoring your logs in case the hackers come back, which they often do.
Your HTTP log shows the visits to your site by HTTP, the request method normally used by ordinary visitors (using their browsers), robots, and hackers.
It’s not always easy to determine which lines in an HTTP log are suspicious and which ones aren’t. At my hack attempt identifier online calculator, you can paste lines from your HTTP log to find out which ones are hack attempts. It classifies the attempts by type so you can see what ways your site is being attacked, and it explains how the different types of attack work.
If you find suspicious changes made to your site (such as file timestamps that are not from when you changed the files yourself), you can try to correlate those changes with the suspicious entries in your log.
For example, a hacked file’s timestamp will often show when the hack occurred (unless the hacker made a special effort not to change the timestamp). If your HTTP log shows a malicious request at the moment of the changed file’s timestamp, that is very suspicious.
It could indicate that the file requested by the hack attempt had a security vulnerability that the hacker was able to exploit with their request. The exploitable file does not have to be the same file that was modified. The exploitable file is just the doorway to get at the other files. In this case, you would examine the requested file (not the modified file) for possible security vulnerabilities. This is how your logs can help identify how a hacker got in.
As another example, if you use a database, and if SQL injection attacks are the only type of hack attempt your site ever receives, SQL Injection becomes your primary suspect.
Your FTP log shows FTP accesses to your site. FTP stands for File Transfer Protocol. In contrast to HTTP, which is most often used to request files for viewing, FTP is a method of transferring files both to and from your server. It’s normally used only by you, the site administrator, but if malicious people or robots manage to log into your FTP as you, they can download your pages, modify them, and upload them back to your website. The only IP addresses in the FTP log should be yours and other authorized FTP users. Make sure the timestamps match times you were logged in and doing transfers.
I’ve seen reports of numerous instances where a webhost spotted in an FTP log a transfer from an IP address other than that of the site owner and immediately informed the owner that their password had been stolen. In too many of these instances, the surrounding circumstances make the webhost’s claim unbelievable. Here is an alternative explanation:
PHP scripts called by RFI attacks sometimes use PHP’s FTP file transfer functions to download additional malicious scripts and related files from a remote server so it can run or install them. The initial RFI includes the remote script into a legitimate script on the victim server, at which point it becomes a part of that script. The script then initiates an FTP transfer, which is recorded in the FTP log. The server does not show its own IP address in the FTP log, but rather that of the second party to the transfer, the remote website. The log of the session makes it appear as though someone logged in (which would have required the password) and initiated an FTP transfer, but in fact there never was a login. There didn’t have to be one, because the session was initiated on the server, from the inside.
Remember this as a possibility if you find IP addresses other than yours in your FTP log or if your webhost tries to convince you too quickly, without considering other evidence, that your password “must have been” cracked. The danger of believing this easy story line (if it is not true) is that it can lead you to believe that all you have to do is change your password. However, if the real initiator of the FTP transfer was an RFI attack, changing your password won’t help at all.
c) Use .htaccess or cPanel > Deny IP to block the hacker’s HTTP access to your site
If you identified the hacker’s IP address, one site where you can look it up to get more information about it is http://whois.domaintools.com/.
Review the instructions in a prior article for how to open .htaccess for editing. As described there, insert the following line in a part of the file that is not enclosed in HTML-like tags.
deny from nnn.nnn.nnn.nnn
The nnn’s are the IP address to block.
If the hacker returns with a different IP that is in the same IP range (i.e. using the same ISP), you can block the whole range for a while, although that carries the risk of banning legitimate visitors, too.
The Apache documentation has instructions for banning a range. Some IP ranges are easily specified using a simple wildcard notation. Others ranges can only be successfully defined using “CIDR/netmask” notation. Although it looks intimidating, it’s easy after the first time you do it. See the separate article describing how to calculate and use the CIDR/netmask.
d) If the hacker has obtained access to your cPanel or FTP, banning their IP address in .htaccess will NOT keep them out of cPanel and FTP.
If they have scripts that they call by HTTP, it will prevent them from doing that, but only until they log into cPanel and un-ban themselves in .htaccess.
13) Report or go after the hacker legally?
Hacking is a violation of the terms of service for any legitimate webhost or ISP. If you can prove conclusively that someone is using a particular IP address for hacking (or spamming, too), you could report the incident to the webhost or ISP in hopes that they might shut the perpetrator down. The contact email is often abuse@ the company.
However, your chances of getting anywhere with this aren’t very great. Even if you succeed, it’s a drop in the bucket. Although you might feel as though you are in a battle of wits with a wily adversary, it is thousands of times more likely that you were hit by an automated drive-by attack that is playing a percentage game, with malicious requests being launched against millions of websites, from hundreds of malicious servers. If one is shut down, it’s just a cost of doing business for them.
It is a more worthwhile use of your time to do everything you can to protect your site from all hackers, regardless of who they are, and understand that there will be a constant flood of attacks against your site.
What to do NOW to protect your website
Website security precautions
Sections 1-6 are absolutely necessary. They do not require a lot of technical knowledge.
1) Maintain strong security on the computer that you use to manage your website
Someone who successfully infects your PC can use it to get into your website. That is very common.
On any Windows PC (does not apply to Linux, Mac) that you use to administer your website, install good quality antivirus software to keep it free of viruses and Trojan downloaders that can install spyware such as keyloggers and password-stealers. Get real-time (“on access”) protection that detects malware immediately when it is received. “On-demand” scanning (such as once a day or once a week) is not good enough. Malware can do all its damage, steal your data, and even delete itself, before you get around to doing a manual file scan.
On a Windows system, once a month, while logged into your PC as an Administrator, visit Windows Update to install the latest security patches for Microsoft products, including Internet Explorer.
Keep all your internet-related software such as browsers, plug-ins, and add-ons up to date with the latest security patches. Examples are Adobe Reader, Flash, and Java. You can check whether your Firefox plugins are up to date at Mozilla Plugin Check.
Use adequate security settings in your web browser. When Internet Explorer and Firefox are first installed, their default security settings are not high enough, and most people don’t change them. Set JavaScript so it is Off by default and only enabled for trusted websites that require it. Follow best practices for IE, and use the NoScript add-on in Firefox.
On a wireless network or in a public “hot spot”, your data is transmitted by radio, and it is easy for someone nearby to monitor everything you send and receive that is not encrypted. Normal web browsing on http:// websites is not encrypted, and neither is a normal FTP login. Whenever you are “working wireless”, use encrypted https:// to log in to your server, and use secure FTP (SFTP) to transfer files.
2) Follow accepted best practices for your website passwords
Use strong passwords: 8 to 20 random upper/lower/numeric/punctuation characters.
Use a different password in every location.
Only give your password to people who must have it.
If you give your password to someone temporarily, change it as soon as their work is finished.
Here is an entire article about why good passwords are so important. It has a strong password generator and password input boxes where you can practice typing strong passwords accurately to get used to them.
3) Choose third party scripts carefully
Don’t load your website with every cool script, gadget, feature, function, and code snippet you can find on the web. Any one of them could let a hacker into your site. Before you use something new, read its vulnerability report at Secunia.com, and do a web search on it to see if people talk about it as a security hazard. Some add-ons and templates are actually designed to be malicious. Ways to avoid those are described by the Google Blogger Team in Keeping Your Blog Secure.
4) Keep third party scripts up to date
Once you have installed a script such as WordPress, SMF, Coppermine, phpBB, or any others, find a way to make sure you are notified quickly when security updates are released. Get on a mailing list, subscribe to an RSS feed, subscribe to a forum board, create a Google Alert, whatever you need to do. When a security update is released, install it within 1 day, if possible.
5) Use good security practices for SSH
SSH, Secure SHell, gives you command line access to your server, allowing you to execute operating system commands from a remote location. Most webhosts don’t allow their shared hosting customers to use SSH at all, but a few do. Resellers and those who manage dedicated servers do have SSH.
If you have SSH access and you use it, its password should be exceptionally strong, 16 random characters or more. I’ve seen servers where the log of failed login attempts was 160MB or more, and the hackers eventually succeeded because the password wasn’t strong enough.
If you have SSH access and you don’t use it, disable SSH so nobody can use it. There is sometimes an SSH control switch in cPanel. For reseller accounts and dedicated servers, there is a switch in WHM. If you are a reseller or run a dedicated server on which there are multiple accounts, turn SSH off for all accounts or at least those that don’t use it. If you allow SSH at all, let your users ask you to enable it for them. Most never will.
6) Don’t weaken your server’s file and folder permissions.
Each file and folder on your server has permissions settings that determine who can read or write that file, execute that program, or enter that folder. Your webhost initially created your webspace with secure permission settings on all files and folders.
Do not modify the permissions until you know what you’re doing. Don’t guess. One mistake can allow any other account on your shared server to put files on your site, or allow anyone in the world to put files there by first getting into a weaker website on your shared server and running a malicious PHP script from there.
People having trouble installing web applications on their site are sometimes told to try setting the Linux permissions to 777 (for folders) or 666 (for files). Those permission levels are sometimes necessary, but they are a hazard and should only be used for folders and files for which it’s absolutely necessary and only during times when it’s absolutely necessary. For example, sometimes 777 only needs to be used during installation or during configuration changes or software upgrades. At other times, the application might function just fine even if you change the permissions back to more secure settings. In other words, if you need to use insecure permissions, try to minimize the amount of time they are in effect. There is no reason to leave permission levels low all the time if you only need them to be that way occasionally. Also, if software installation instructions tell you to delete the installation script itself after use, remember to do it. If it’s left on the server, someone else who knows it’s there (or knows it should be there) can run it, just like you can.
These precautions are also absolutely necessary, but only if you write your own program code.
For the language you use, find and read an overview about security: PHP, ASP.NET, Cold Fusion, …
When you use an unfamiliar function for the first time, check the manual for security considerations.
Learn to instinctively distrust data from the outside world. Write your code so that incoming malicious input can’t trick it into doing something it shouldn’t. Outside data includes: incoming form submission data, HTTP query strings, cookies.
There are lots of online resources for learning how to code securely. All it takes is a web search.
For PHP, use a good php.ini file for extra security, to block common attacks.
8) Block suspicious activity with .htaccess
These are extra precautions that provide an additional layer of security. If you understand what this section is talking about, the discussion and code examples should help you to put some good protections in place. If you don’t understand this section, don’t worry about it unless you are under constant attack and other remedies have failed.
Download and examine your raw access logs, or analyze the lines here. You will most likely find attacks of the types described in my articles. Even if the attempts are unsuccessful, your logs give early warning about what methods are being used, which gives you time to figure out how to defend against them. Here are some examples of how to block suspicious activity:
Ban bad robots.
One program often misused for automated remote file inclusion attacks is called “libwww-perl”. The RFI cannot succeed if your server refuses to serve the file, so blocking this commonly malicious User-Agent is one defense. Put the following lines in your public_html/.htaccess, in a part of the file that is not delimited by HTML-style tags like <tag></tag>:
SetEnvIfNoCase User-Agent libwww-perl block_bad_bots
# to deny more User-Agents, copy the line above and change
# only libwww-perl, to match the new name.
deny from env=block_bad_bots
SetEnvIfNoCase does a case-insensitive test of the User-Agent against a regular expression, which in this case is “contains libwww-perl”. If it matches, it sets the variable block_bad_bots. The final line says if block_bad_bots was set (i.e. if the requestor matched any of the bad robots), deny the request and send a 403 Forbidden error instead. Regardless of what the bad robot was trying to do, it won’t succeed.
Ban suspicious URL query strings.
Another defense against RFI is to block all requests having the form:
GET /index.php?inc=http://badsite.com/badscript.txt?
The following .htaccess code blocks any request where the query string (the part after the first question mark) contains “=http://” or “=ftp://”. During times when you need to use a query string of that type yourself, you can comment out the code block or enable the exception shown:
# If the next line is already in your .htaccess, you don’t need to add a 2nd one.
RewriteEngine On
RewriteCond %{QUERY_STRING} ^.*=(ht|f)tp\://.*$ [NC]
# Allow yourself, for SMF Forum Package Manager upgrades.
# Set it to your own IP address so you are the only one who won’t be blocked.
#RewriteCond %{REMOTE_ADDR} !^111\.222\.333\.444$ [NC]
RewriteRule .* – [F,L]
To test: you should get a 403 Forbidden error when you try to go to:
If you have coded your pages so they use remote file includes from your own site or from some external site (such that your site receives requests, constructed by you, that have URLs in the query strings), my first advice is that you should try to stop doing that:
Instead of sending your own site a request that has a URL in the query string, you can put in the query string a text string that the receiving page translates into a URL after it receives it. That way, your script can’t be tricked by someone who sends it a malicious URL instead of one of the legitimate ones it expects.
If you must send your own site requests that have URLs in the query strings, you can use a more complicated .htaccess to allow your own remote file inclusion requests but ban others:
# FIRST, DISALLOW QUERY STRINGS CONTAINING MORE INSTANCES OF http://
# THAN WE EVER USE OURSELVES, TO LIMIT THE NUMBER OF TESTS WE MUST DO LATER.
# THIS EXAMPLE ALLOWS ONLY INSTANCE PER QUERY STRING.
RewriteCond %{QUERY_STRING} (.*http(\:|%3A)(/|%2F)(/|%2F).*){2,} [NC]
RewriteRule .* – [F,L]
# NOW WE CAN TEST EACH INSTANCE AGAINST THE LIST OF SITES WE WANT TO ALLOW.
# SINCE THIS IS A NEW REWRITE RULE, WE MUST TEST AGAIN WHETHER IT CONTAINS http://
RewriteCond %{QUERY_STRING} http(\:|%3A)(/|%2F)(/|%2F) [NC]
# THEN FALL THROUGH TO THE BAN IF IT IS NOT ONE OF THE SITES IN OUR ALLOW LIST.
RewriteCond %{QUERY_STRING} !(http(\:|%3A)(/|%2F)(/|%2F)(www\.)?site1\.com) [NC]
RewriteCond %{QUERY_STRING} !(http(\:|%3A)(/|%2F)(/|%2F)(www\.)?site2\.com) [NC]
#ADD A LINE FOR EACH EXTERNAL SITE YOU WANT TO ALLOW TO APPEAR IN QUERY STRINGS.
RewriteRule .* – [F,L]
Allowing for more than one instance of http:// in your query strings is possible. It requires complex code that we can custom design for you if needed.
Other query string bans:
1) Malicious RFI attempts almost always have a question mark at the end of the query string. Ban any query string that contains a question mark. The first question mark (which marks the beginning of the query string) is not part of the query string, so only question marks after the first one will trigger the ban:
2) Be creative: find other characteristics that are common in the attacks on your site but that are never present in legitimate requests. Be thorough: use every good ban rule you can think of. It is very satisfying to see an attack on your site and know that even though it only needed to trigger one ban rule to fail, there were six others in reserve that it would have triggered.
Ban IP addresses responsible for suspicious activity.
You can block IP addresses (or ranges) in .htaccess or by cPanel > Deny IP. Although such bans can be useful against IP addresses you are 100% certain will never make a legitimate request, they aren’t otherwise very practical. Once a botnet starts attacking your site, the requests will come from hundreds of different IPs, and banning them all will be futile. It is much better to ban by the other characteristics of the requests.
See this forum thread for further discussion about using .htaccess to block malicious requests, links to websites with suggested .htaccess code for blocking such requests, and a basic introduction to help understand the Perl regular expressions that are used for pattern matching in .htaccess.
Preparations that will make hack diagnosis and cleanup easier
1) Always have a backup copy of your entire website and its databases
You can use FTP and/or cPanel > Backups. Keep the backup somewhere not on your server, such as on your local PC or a DVD. Even if your webhost does backups, make a separate set for yourself. Do a new backup whenever there is enough new content that you don’t want to have to redo the work. Keep more than one “generation” of backups. For example, if you backup monthly, keep separate versions from 1 month ago and from 2 months ago. This guards against backing up your site after it’s been infected but before you discovered it. You’ll still have (hopefully) a slightly older backup that isn’t infected. For the same reason, don’t backup too often.
2) Turn on log archiving in cPanel now
Your raw HTTP and FTP logs are an important source of information after an attack, but the logs are normally deleted each day. Enable archiving to allow them to accumulate and preserve the evidence after an attack. Periodically download and review the logs to see what kinds of attacks are being launched against your site. As is so often the case, becoming familiar with what is normal will help you detect when something is not. Accumulated logs can take a lot of disk space, so you might want to delete old ones from the server periodically.
3) Get a complete list of your site files NOW while they are known-good
This article describes how to get a list of all the files in your website. If you do it now, it will be a baseline list of the files you can assume are supposed to be there. If your site gets damaged, the list will help you decide whether a file you don’t recognize is new or is just a system file that you never noticed before.
4) Explore your website and become familiar with what is there
Not just your pages, but the whole site, using FTP or File Manager or the complete file list you made. If you get used to what is normal, things that aren’t will catch your attention.
5) Use good database connection practices in scripts:
a) Create separate MySQL users for your scripts to use
If you use your cPanel userID and password for database connections in your scripts, then changing your cPanel password will instantly break all your scripts until you recode them to use the new password.
Instead, create one or more new users, completely unrelated to your cPanel login, that your scripts can use for their database connections:
Go to cPanel > MySQL® Databases > Current Users.
In Username: enter the name of the user to create. Although the existing user names might appear as YourUserID_username, don’t enter the prefix and underscore. cPanel will do that for you, if needed.
In Password: enter the password to use. Make it a strong one.
Click Create User, read the confirmation screen, and then Go Back to the MySQL Account Maintenance page.
Go to the Add Users To Your Databases section.
In the left dropdown box, select the user you just created.
In the right dropdown box, select the database you want that user to be able to connect to.
Select the Privileges you want that user to have for that database, by checking the appropriate boxes. Select only the privileges the user really needs for performing whatever tasks your scripts will do. Granting only limited privileges is a security precaution.
Click Add User To Database. Your new user now has the specified privileges, for that database only. Add the user to other databases, if needed.
Now update your scripts so they use the connection data for this new user instead of your old cPanel user. However, …
b) Put your MySQL connection data in a well protected file
If each of your scripts has its own code block for database connection, then if you are hacked and have to change your passwords, you’ll have to hunt through all your files to find every code block that needs changing.
Instead, put all your database connection code in one central location such as an include file that is well-protected from web access, and make all your scripts read it from there. There are examples and some discussion about how to do this in the User Contributed Notes at http://us.php.net/mysql_connect. You can protect your include file by putting it in a folder above public_html, or in any folder that is closed to web access by an .htaccess file, or by the other methods mentioned in the php.net Notes.
Unfortunately, none of these protection methods will keep your data safe from someone who has actually gotten into your site, but the new database connection method you have just created will make it easy to change your password (in just one place) if that does happen.
Thanks again for a comprehensive article!
Anyone who works with CMS should familiarize themselves with some of these basic practices of webmastering, before you get hacked. But if it has already happened, this is ESSENTIAL.
A great reference article by 25 Years of Programming An open source source for C, C++, OWL, BASIC, MDB, XLS, DOT, and more…
For most cPanels, this won’t be much different than GoDaddy’s.
After your certificate request is approved, you can download your SSL and intermediate certificate from within the SSL application. For more information see Downloading Your SSL Certificate. Both of these files must be installed on your Web server.
You may also download the intermediate certificate from the repository.
To Install SSL and Intermediate Certificates
These instructions require that you have a copy of our certificate bundle, gd_bundle.crt. You can download the certificate bundle from the repository.
Open the WebHost Manager and click Install an SSL Certificate in the SSL/TLS menu.
You will see a screen with three boxes on it. Your issued certificate, RSA private key and certificate bundle must be pasted into boxes 1, 2, and 3, respectively.
In the first box, paste in the contents of your issued SSL certificate. If the certificate file is on your server, you may use the Fetch button to copy it from the file.
In the second box, paste in your private key which was generated when you created the CSR.
In the third box, paste in the certificate bundle (gd_bundle.crt).
Distributed Denial-of-Service attacks of the old already have mitigation steps being practiced by network professionals today. Internet service providers have disabled accepting ICMP echo requests, used ingress filtering for spoofed source address and have limited their opened ports. All of this mitigation affects only the network and transport layer of the OSI protocol stack.
The techniques described above don’t work against bot threats which use a legitimate way in retrieving Internet resources. It does not spoof its source address, it does not send ICMP packets, and it does not use ports other than the HTTP port. The attacks usually originate from a compromised machine with multiple threads or processes that connects to a website simultaneously.
The HTTP port is used by browsers to access a web page and this port sits on the application layer of the OSI protocol stack which does not have any established mitigation steps against DDoS attacks. The application layer is where data have been decapsulated or stripped of its transmission details between machines and protocols.
Flash Crowd Effect
Mitigation steps against HTTP-based DDoS attack varies between internet service providers (ISPs) and network administrators. The reason behind this is because it is hard to distinguish legitimate traffic from an attack coming from a botnet. The botnet DDoS mimics an event that a flash crowd visitor creates.
Bandwidth Over-Provisioning
The obvious solution for this is to have bigger bandwidth to support all the requests; the same way that a hosted website upgrades to a costlier hosting plan as it grows in popularity and generates huge traffic. Instead of upgrading the subscription, there are already commercial anti-DDoS services which provide additional bandwidth in the event of flash crowds.
Clean Pipes Services
Companies serving DDoS defense also have services which involve packet scrubbing. This uses high performance network appliances and computers to inspect packets content and behavior before forwarding the packets to its destination. It hooks the website IP address and catches all the packets in the event of DDoS and inspects them of how they react to responses sent by the defense. If the connecting host is legitimately accessing the site, the packet is then forwarded to the hosting server.
Solutions for the Web Developer
In case the website is hosted via a web-hosting provider, the site owner does not have any access to the network devices to control and filter traffic. For the site owners on the budget, there have been proposed solutions that can be used by their site developers.
It involved the use of a reverse Turing test, which gives a challenge to the connecting hosts. One example of reverse Turing test is the use of CAPTCHA which contains words or sound that humans can easily understand but not computers. When a source IP address tries to access a URL repeatedly within a short time frame, the challenge routine is triggered. If the machine does not reply or incorrectly answers, an HTTP 503 response (Service Unavailable) is always sent to the source IP address until the DDoS subsides. The Service Unavailable response is the cheapest way to send to a connecting host in terms of bandwidth.
Tarpits to Control DDoS Bandwidth
For network administrators that don’t have access to high performance network appliances or services, there’s a passive way to mitigate DDoS and it’s called tarpitting. It is deployed by network administrators in their gateway firewall which is the boundary of their intranet and their ISP.
Tarpitting works by taking advantage of TCP, a protocol which the botnet must follow to send and receive packets. Once the offending source is detected, the victim’s firewall forwards the connection to a tarpitted address. The tarpitted address has its TCP window size set at the minimum. This causes the offending machine to send further data having the same size that it received from the tarpitted address. The result more bandwidth is served to legitimate users.
Tarpits for Retaliation
In normal DDoS attack where an attacker initially sends a synchronization packet (SYN), the victim replies with a synchronization and acknowledgment packet (SYN-ACK) which is completed by the offending machine with an acknowledgment packet (ACK). Completing this three-way handshake is what differentiates this attack from SYN floods which already have defense technology built in routers and operating systems.
In a tarpitted connection, the victim only replies to SYN packets with a SYN-ACK having a zero TCP window size. Without the victim replying to other packets, the attacking machine will have multiple open connections. These connections made by the offending machine will only be closed when time-out is reached or if the attacking machine can’t handle too many open connections causing it to crash – sort of like attacking itself with DoS.
Cooperation is the Key
Security and network professionals agree that the best thing to mitigate, if not eradicate, DDoS attacks is to have cooperation. Information sharing between security and network community will help standardize the best practices how systems and applications interact to process data efficiently. Information from the victim network should be relayed to the ISP nearer to the attacking machine in order to block DDoS packet. Cybercrime laws should be enforced to get the cooperation of ISPs and infected companies’ intranets that send DDoS packets to clean their networks. Until we get this to reality, we just have to accept that DDoS threats from botnets are unstoppable if handled alone.
These are suggested methods to prevent distributed denial of service attacks.
Use the ip verify unicast reverse-path interface command on the input interface on the router at the upstream end of the connection.
This feature examines each packet received as input on that interface. If the source IP address does not have a route in the CEF tables that points back to the same interface on which the packet arrived, the router drops the packet.
The effect of Unicast RPF is that it stops SMURF attacks (and other attacks that depend on source IP address spoofing) at the ISP’s POP (lease and dial-up). This protects your network and customers, as well as the rest of the Internet. To use unicast RPF, enable “CEF switching” or “CEF distributed switching” in the router. There is no need to configure the input interface for CEF switching. As long as CEF is running on the router, individual interfaces can be configured with other switching modes. RPF is an input side function that enabled on an interface or sub-interface and operates on packets received by the router.
It is very important for CEF to be turned on in the router. RPF does not work without CEF. Unicast RPF is not supported in any 11.2 or 11.3 images. Unicast RPF is included in 12.0 on platforms that support CEF, which includes the AS5800. Hence, unicast RFP can be configured on the PSTN/ISDN dial-up interfaces on the AS5800.
Filter all RFC-1918 address space using Access Control Lists (ACLs).
Refer to this example:
access-list 101 deny ip 10.0.0.0 0.255.255.255 any
access-list 101 deny ip 192.168.0.0 0.0.255.255 any
access-list 101 deny ip 172.16.0.0 0.15.255.255 any
access-list 101 permit ip any any
interface xy
ip access-group 101 in
Another source of information about special use IPv4 address space that can be filtered is the (now expired) IETF draft ‘Documenting Special Use IPv4 Address Blocks that have been registered with IANA .’
The ISP edge router should only accept traffic with source addresses belonging to the customer network. The customer network should only accept traffic with source addresses other than the customer network block. This is a sample ACL for an ISP edge router:
access-list 190 permit ip {customer network} {customer network mask} any
access-list 190 deny ip any any [log]
interface {ingress interface} {interface #}
ip access-group 190 in
This is a sample ACL for a customer edge router:
access-list 187 deny ip {customer network} {customer network mask} any
access-list 187 permit ip any any
access-list 188 permit ip {customer network} {customer network mask} any
access-list 188 deny ip any any
interface {egress interface} {interface #}
ip access-group 187 in
ip access-group 188 out
If you are able to turn on Cisco Express Forwarding (CEF), the length on the ACLs can be substantially reduced and thus increase performance by enabling unicast reverse path forwarding. In order to support unicast reverse path forwarding, you only need to be able to enable CEF on the router as a whole; the interface on which the feature is enabled does not need to be a CEF switched interface.
Use CAR to rate limit ICMP packets.
Refer to this example:
interface xy
rate-limit output access-group 2020 3000000 512000 786000 conform-action
transmit exceed-action drop
access-list 2020 permit icmp any any echo-reply
Configure rate limiting for SYN packets.
Refer to this example:
access-list 152 permit tcp any host eq www
access-list 153 permit tcp any host eq www established
interface {int}
rate-limit output access-group 153 45000000 100000 100000
conform-action transmit exceed-action drop
rate-limit output access-group 152 1000000 100000 100000
conform-action transmit exceed-action drop
In the previous example, replace:
45000000 with the maximum link bandwidth
1000000 with a value that is between 50% and 30% of the SYN flood rate
burst normal and burst max rates with accurate values
Note that if you set the burst rate greater than 30%, many legitimate SYNs may be dropped. In order to get an idea of where to set the burst rate, use the show interfaces rate-limit command in order to display the conformed and exceeded rates for the interface. Your objective is to rate-limit the SYNs as little as necessary to get things working again.
Distributed denial-of-service (DDoS) attacks have been popular for a simple reason: they work. The results of a DDoS attack can be crippling. An attacker can use a DDoS attack to shut down a business, for example, or prevent a political adversary from sharing opinions. Before the rise of DDoS attacks in 1999, attackers usually launched denial-of-service attacks from a handful of networked machines. When tools like Trinoo and Tribe Flood Network 2000 were widely released, launching a flood from thousands of machines became quite easy. Today, most DDoS attacks are launched from botnets, which are comprised of tens of thousands of machines or more. Some current reports claim there are a few botnets boasting more than a million infected machines.
During the past few years, service providers have been implementing more proactive defenses, using automated sensors and blocking technology to look for unusual traffic patterns that are often associated with a DDoS attack. Mechanisms, implemented in tools like Arbor Networks Inc.’s Peakflow, Cisco Systems Inc.’s Guard DDoS mitigation appliances and Mazu Networks Inc.’s Enforcer, look for the tell-tale sign of a SYN flood.
Before discussing SYN flood detection mechanisms, it’ll be useful to review the process of a Transmission Control Protocol (TCP) connection. Read More…
A denial of service (DoS) attack is an incident in which a user or organization is deprived of the services of a resource they would normally expect to have. In a distributed denial-of-service, large numbers of compromised systems (sometimes called a botnet) attack a single target.
Although a DoS attack does not usually result in the theft of information or other security loss, it can cost the target person or company a great deal of time and money. Typically, the loss of service is the inability of a particular network service, such as e-mail, to be available or the temporary loss of all network connectivity and services. A denial of service attack can also destroy programming and files in affected computer systems. In some cases, DoS attacks have forced Web sites accessed by millions of people to temporarily cease operation.
Common forms of denial of service attacks are: Read More…
But Size (GBs) Does Matter and So Does Speed (RPM)
When 2 Drives Are Better than One
Purchasing a hard drive (HDD) is an important buying decision. That’s because all your data is saved on it. If you buy a low quality hard drive it may crash on you and you’ll lose all your games and all your digital data. In the end, though, hard drives are all about capacity. And, far more often than not, your biggest hard drives are the costliest. However, once the new models hit the market you will be able to purchase the earlier generation models for less cash. Additionally, the higher-performance (7200-rpm) drives are usually pricier than the more pedestrian (5400-rpm) drives at the same capacity.
Choosing a Top-Notch Hard Drive
Capacity – We recommend at least 160 to 500GB; but the more the merrier!
RPMs – Go for 7200RPM – it gives you faster read and write speed.
Interface Speed – To get the max from your HDD the interface speed must match the interface speed of your PC.
Seek Speed – Not a huge deal. It’s how fast drives can pick a particular piece of data. 8ms or lower is an exceptional seek speed, but 8ms to 9ms is just fine.
Buffer Size – Go for at least 2MB
Bigger is Better
It’s generally a smart move to purchase the biggest hard drive capacity your budget will bear, even if you won’t need all that drive space right away. Of course, larger hard drives cost more than smaller ones, but the cost per GB doesn’t work out byte for byte. For example, the difference in cost between a 60GB and an 80GB HDD isn’t much, but a huge HDD could cost quite a bit more. Hard drives are able to handle larger amounts of data all the time. And it’s a good thing, because programs are getting more complex, graphics-intensive. You can now hold an amazing 400GB of data on a single drive. For those of you who hoard vast amounts of digital media or edit videos this ever-burgeoning hard drive capacity is a gift from cyber heaven. The proliferation of extra-large hard drives takes away some of the mystery out of HDD shopping. However, determining what size hard drive you need is a subjective matter. It really depends on how much data you need to store. Some folks can get by with 60GB on a desktop; others prefer the huge hard drives ranging from 250Gb all the way to 2.0TB or more. Size requirements, of course, differ for notebook computers. Before you get too involved in the GB numbers, though, you will need to check your motherboard’s manual or with your computer manufacturer to see how big a hard drive your PC can support. We recommend that you start off with at least an 80GB hard drive.
The Need for Speed
The speed of a hard drive is expressed in revolutions per minute (RPM) and it refers to how fast the computer can read data from the hard drive. We recommend that your hard drive moves at a clip of at least 7200 RPM. At less than 7200RPM your data-intensive applications, such as games, might slow down because it takes too long access the data.
You need at least 5400 RPM for fast data read and write speed. High RPM is especially critical if you use your computer for multimedia or video applications. Faster RPM doesn’t make much difference for word processing or surfing the Net.
Secondary Considerations: Interface and Seek Speeds, as well as Buffer Size
Secondary considerations that taken together should have an impact on your buying decisions include Interface Speed, Seek Speed and Buffer Size.
Interface Speed
Interface speed is measured in ATA/100 or ATA/133. There isn’t much noticeable difference between the two values. To get the maximum performance from your hard drive, its interface speed must match the interface speed of your PC. If not, you must install an interface card that matches the speed of the new drive.
Seek Speed
Average seek speed is how fast your drive can find a particular piece of data. This should not be a huge factor in your hard drive buying decision unless you need to copy large folders full of many small files, which makes it necessary for your PC to assemble small, scattered bits of data.
Buffer Size
The buffer is a memory cache on the drive. This cache is a repository for the temporary storage of data awaiting the next likely request of your computer’s CPU. Because random-access-memory (RAM) is much faster than mechanical rotating storage, the buffer can speed up performance. Most new desktop hard drives have buffers of at least 2MB, which is perfectly acceptable for most uses.
Other Considerations:
RAID
SATA
Moving Data to Another Drive
RAID!! What is it? Do You Need it?
In case you are interested, RAID stands for Redundant Array of Independent Disks. Simply stated, RAID allows you to use more than one hard drive to ratchet up your disk speed or retain a backup of your data in case a drive fails. In either circumstance, you will need more than one identical drives, and it’s not particularly easy to configure them. More and more systems use RAID 0, which can markedly increase system speeds for reading and writing data. If you want to go for RAID you will need to choose a couple of drives that match the storage capacity you’re looking for. Now that you can purchase 1.0TB hard drives for less than $100, you can easily go for the RAID advantage. Making this decision easier is the fact that most new motherboards support Redundant Array of Independent Disks.
Take Serial ATA Seriously?
Serial ATA, known as SATA is definitely the way to go if you are building your own PC from the ground up. Even the most inexpensive mobos support SATA, and if you go with a SATA drive your PC system will be easier to set up. Plus, you’ll have a much easier time moving your drive to a future PC. Now if you want to boost the storage capacity of an older PC, choosing SATA is not such a simple proposition. In order to use a SATA drive you’re going to have to add a SATA controller card, which can be costly. However, many of the new SATA controller cards have built-in options to add RAID support to your system. If you’re a video editor or the kind of person who stores tons of digital data, it just might be worth your while. In the alternative, it’s a wise choice to simply add a second parallel ATA drive. Some manufacturers are adding new wrinkles to SATA technology to enhance hard drive performance. For example, Seagate’s Native Command Queuing (NCQ), which requires a native Serial ATA drive, accompanies one of its 160GB hard drives, improves performance by packing good aerial density, meaning it has more data than ordinary into a small space. NCQ allows the drive to master multiple outstanding commands simultaneously and utilizes an internal queue that can store up to 32 commands at once to allow the drive to quickly reorganize the commands so they can be written and read more efficiently. This particular Seagate drive with NCQ also uses 8MB of cache to help overall performance by caching sequential data hits.
Moving Your Data to Another Drive
When it comes time to add a new hard drive to your older PC, the new addition will almost always be faster than your existing drive. However, if all you do is install the new drive on your PC, you’re going to maroon your operating system on the slower drive. In committing such an act of abandonment, you will forfeit some of the benefits of upgrading. So, make sure you use the newer, speedier hard drive as your boot drive. Hard-drive upgrade kits generally include software that will clone your existing drive to the new one, thus turning your faster drive into your boot drive.
Mechanisms, implemented in tools like Arbor Networks Inc.’s Peakflow, Cisco Systems Inc.’s Guard DDoS mitigation appliances and Mazu Networks Inc.’s Enforcer, look for the tell-tale sign of a SYN flood.
Comments Off