Full Version: Preventing hacking
.
maybe it was configured so you can't login to ssh using root user.
the best is to login using a common user and then "su" to the root, if you need it.
there is some common security hardening measures to do on a linux server (no silver bullets):
1. Upgrade Apache/PHP, openssh, openssl, mysql etc.
Nothing new here, but you'll make sure your running the latest secure versions of commons software components. This is the first step in preventing your server getting cracked by common exploits. Usually there are no downsides, but if you have specific version requirements for particular apps, some upgrades should be made with caution.
2. Firewall Installation.
Please be aware this is not a silver bullet, and these do not prevent exploits of services you do run. You will also need to be aware you have a firewall and may need to open up additional ports as needed if you add new services.
3. Rkhunter Installation.
Although not a preventative mechanism, it can be useful to detect any failures in your layers of defense. It's a cron job that scans your system for rootkits, exploits, trojans and backdoors.
http://www.rootkit.nl/projects/rootkit_hunter.html
No downsides, although there can sometimes be false alarms.
4. Mod_Security Installation.
Mod security is effectively a firewall for web based apps and can help prevent attacks on programs that would otherwise be vulnerable.
This can be fine tuned, but you may limit some "power" user customers (easily rectified).
http://www.modsecurity.org
5. /tmp hardening.
Many attacks and exploits use /tmp to work out of any propogate themselves. By making /tmp a seperate partition and mounting it noexec and nosuid (meaning executables cannot be run from /tmp nor with escalated privileges), this stops many of these exploits from being able to do any harm.
A potential downside is making /tmp too small for some operations like account backups/transfers.
6. Disable non-root access to unsafe binaries.
Many exploits use well known executables already on your system as part of their bag of tools. By only allowing privileged users access to these files, you can cause many attacks to not function.
You may find some binaries like "wget" too useful to limit access to, despite being useful to crackers too.
7. Disable SSH root access.
Root ssh is bad because a brute force attack can use the known username 'root' and concentrate on password variations. By using a unique username (not something like admin) you creatly reduce the chance of a successful brute force attack.
Some people use root ssh in the form of ftps to access the entire filesystem. There are several ways to workaround this, like creating a new user with uid 0 as well. You also need to be aware of this when requesting support, and give to your support team the no-root login info.
8. Change SSH Port.
An additional layer of security is to change the default ssh port to something else. Although this is akin to security by obscurity, it can let you completely avoid many script kiddy atacks.
Like non-root ssh, you need to be aware of this when requesting support, and give to your support team the alternate port info.
9. PHP suEXEC support.
When PHP runs as an Apache Module it executes as the user/group of the webserver which is usually "nobody" or "apache". php suEXEC changes this so scripts are run as a CGI.
This means scripts are executed as the user that created them. If user "snow" uploaded a PHP script, you would see it was "snow" running the script when looking at the running processes on your server. It also provides an additional layer of security where script permissions can't be set to 777 (read/write/execute at user/group/world level).
The downside however is that there can sometimes be issues with any .htaccess directives you have, specifically in regards to PHP directives. You may have to remove PHP directives from .htaccess and move them into a php.ini file inside of your site's document root. In addition, there could be some performance loss (also known as seeing a higher server load) as a result of all php scripts being ran as a seperate CGI instead of as part of the Apache module.
just my 2 cents
the best is to login using a common user and then "su" to the root, if you need it.
there is some common security hardening measures to do on a linux server (no silver bullets):
1. Upgrade Apache/PHP, openssh, openssl, mysql etc.
Nothing new here, but you'll make sure your running the latest secure versions of commons software components. This is the first step in preventing your server getting cracked by common exploits. Usually there are no downsides, but if you have specific version requirements for particular apps, some upgrades should be made with caution.
2. Firewall Installation.
Please be aware this is not a silver bullet, and these do not prevent exploits of services you do run. You will also need to be aware you have a firewall and may need to open up additional ports as needed if you add new services.
3. Rkhunter Installation.
Although not a preventative mechanism, it can be useful to detect any failures in your layers of defense. It's a cron job that scans your system for rootkits, exploits, trojans and backdoors.
http://www.rootkit.nl/projects/rootkit_hunter.html
No downsides, although there can sometimes be false alarms.
4. Mod_Security Installation.
Mod security is effectively a firewall for web based apps and can help prevent attacks on programs that would otherwise be vulnerable.
This can be fine tuned, but you may limit some "power" user customers (easily rectified).
http://www.modsecurity.org
5. /tmp hardening.
Many attacks and exploits use /tmp to work out of any propogate themselves. By making /tmp a seperate partition and mounting it noexec and nosuid (meaning executables cannot be run from /tmp nor with escalated privileges), this stops many of these exploits from being able to do any harm.
A potential downside is making /tmp too small for some operations like account backups/transfers.
6. Disable non-root access to unsafe binaries.
Many exploits use well known executables already on your system as part of their bag of tools. By only allowing privileged users access to these files, you can cause many attacks to not function.
You may find some binaries like "wget" too useful to limit access to, despite being useful to crackers too.
7. Disable SSH root access.
Root ssh is bad because a brute force attack can use the known username 'root' and concentrate on password variations. By using a unique username (not something like admin) you creatly reduce the chance of a successful brute force attack.
Some people use root ssh in the form of ftps to access the entire filesystem. There are several ways to workaround this, like creating a new user with uid 0 as well. You also need to be aware of this when requesting support, and give to your support team the no-root login info.
8. Change SSH Port.
An additional layer of security is to change the default ssh port to something else. Although this is akin to security by obscurity, it can let you completely avoid many script kiddy atacks.
Like non-root ssh, you need to be aware of this when requesting support, and give to your support team the alternate port info.
9. PHP suEXEC support.
When PHP runs as an Apache Module it executes as the user/group of the webserver which is usually "nobody" or "apache". php suEXEC changes this so scripts are run as a CGI.
This means scripts are executed as the user that created them. If user "snow" uploaded a PHP script, you would see it was "snow" running the script when looking at the running processes on your server. It also provides an additional layer of security where script permissions can't be set to 777 (read/write/execute at user/group/world level).
The downside however is that there can sometimes be issues with any .htaccess directives you have, specifically in regards to PHP directives. You may have to remove PHP directives from .htaccess and move them into a php.ini file inside of your site's document root. In addition, there could be some performance loss (also known as seeing a higher server load) as a result of all php scripts being ran as a seperate CGI instead of as part of the Apache module.
just my 2 cents
Wow! Tell me this guy isn't amazing.
That's exactly how my server's setup, thanks to Martin.
Before Martin =
After Martin =
That's exactly how my server's setup, thanks to Martin.
Before Martin =
After Martin =
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.