Advanced firewall and testing

abillionwishes · 12-14-2010, 03:51 PM

Dear all,

Yesterday I launched my website. At the moment the site has an firewall (iptables) enabled with very simple rules. All incoming traffic is blocked, except for the ports http and ssh.

Everything is working perfect, but I want also to be able to block certain kinds of attacks. Can somebody help me with this? There are some really good examples on the internet, but I don't now if they contain all kinds of attacks which are relevant to my situation. To be clear, I only server web content through port 80 and use ssh to remote login.

It would be a real help to me if you could give me some hints on what things I should be aware of.

Finally, [MODERATED]

Thank you all for your input and interest!

unSpawn · 12-15-2010, 08:10 AM

Quote:

Originally Posted by abillionwishes

I want also to be able to block certain kinds of attacks. I only server web content through port 80 and use ssh to remote login.

Attacks can be looked at and learned from in different ways:
Reconnaissance vs targeted: most noise you'll encounter will be automated scanning. Rattling the door, harvesting results and returning back later is more efficient and can be done by anyone and from anywhere. Scanning is harmless if vulnerabilities they look for don't exist but if they do at least you've got a chance to mitigate the situation:
- restrict access on the system, network and application level to any area dealing with application management,
- make 'net-facing user accounts use an inert shell, deny use of cron and at and do not allow them to traverse the whole file system,
- ensure you log violations, have them reported to you daily and act on them immediately,
- use proactive measures where possible.

Prevalence: part due to popularity of PHP-based applications, general misconfiguration and failure to replace vulnerable software versions, web stack compromises these days are more widespread than root compromises:
- invest time reading and practicing: knowing how to run what you run gives you a better chance of survival,
- remove any default components after installation like default passwords, tables, directories and files,
- disable web application features you do not need and remove any plugins or addons that are not officially endorsed or actively maintained or supported,
- update web-facing components, dependencies and web applications when updates are released.

Quote:

Originally Posted by abillionwishes

Yesterday I launched my website. (..) give me some hints on what things I should be aware of.

...but all of the above starts with good preparation. You really should have asked that before making your site publicly accessible and not as an afterthought.
Generally speaking:
- draw a plan and stick to it. You will get lost in details.
- use a current, maintained release of the OS and preferably choose a distribution with longterm support,
- do not install what you do not need now,
- install and regularly run one or more integrity checkers,
- install updates when they are released,
- harden your OS and web stack before exposing it: read your distribution or general documentation,
- do not disable additional security features like AppArmor, SELinux or GRSecurity because the documentation of your web application can handle it or if you can't be bothered to grok it. (Yes, that sounds harsh but unfortunately that's reality for ya.),
- test your setup regularly from a remote account,
- deploy a backup scheme,
- never log in over the network as root user.

Any questions just ask but it would be good if you could fill in details like distribution + release, what web applications + versions you run.

abillionwishes · 12-19-2010, 05:43 AM

Wow! That's some real help you're providing there. Thank you for that! I'm definitely going print the post and hang it next to my monitor.

At the moment my server runs on minimal configuration. At least I didn't install more than I needed. To give you an idea, here is an list of program's I'm running. By the way I'm running Ubuntu 10.04 with the latest updates installed.

SSH (For remote login. This was already installed on my VPS because I don't have any direct access to the system.)
Apache server (Apache/2.2.14 (Ubuntu))
PHP (Version 5.3.2-1ubuntu4.5)
MySql database (Ver 14.14 Distrib 5.1.41, for debian-linux-gnu (i486) using readline 6.1)

Here some specific details about Apache server
Loaded modules

Code:

Compiled in modules:
  core.c
  mod_log_config.c
  mod_logio.c
  prefork.c
  http_core.c
  mod_so.c

Here some specific details about PHP:
Loaded modules

Code:

core mod_log_config mod_logio prefork http_core mod_so mod_alias mod_auth_basic mod_authn_file mod_authz_default mod_authz_groupfile mod_authz_host mod_authz_user mod_autoindex mod_cgi mod_deflate mod_dir mod_env mod_mime mod_negotiation mod_php5 mod_reqtimeout mod_setenvif mod_status

All the PHP scripts are written defensively. By defensively I mean:

I don't trust the input.
All GET and POST values are validated.
Only the request which is expected, is handled. So, when expecting a GET request the script will reject an POST request and visa versa.
Input values needed to query the database are carefully inspected for any form of SQL injection.

Does this sound as a good start?

At the moment I'm logging all kind of things. Do you have a good link on this subject?

unSpawn · 12-19-2010, 12:06 PM

Quote:

Originally Posted by abillionwishes

SSH (For remote login.

As long as you don't log in as root over the network (also see fail2ban and http://www.linuxquestions.org/questi...tempts-340366/).

Quote:

Originally Posted by abillionwishes

PHP (Version 5.3.2-1ubuntu4.5)

Apart from any vulnerabilities in PHP itself it often not as much about PHP as it is about what people run on top of it. (This http://www.linuxquestions.org/questi...ackets-850901/ being a nice recent example of somebody running deprecated software.)

Quote:

Originally Posted by abillionwishes

Here some specific details about PHP:
Loaded modules

Code:

core mod_log_config mod_logio prefork http_core mod_so mod_alias mod_auth_basic mod_authn_file mod_authz_default mod_authz_groupfile mod_authz_host mod_authz_user mod_autoindex mod_cgi mod_deflate mod_dir mod_env mod_mime mod_negotiation mod_php5 mod_reqtimeout mod_setenvif mod_status

Sure if your software requires all those modules to be loaded...

Quote:

Originally Posted by abillionwishes

All the PHP scripts are written defensively. By defensively I mean:

I don't trust the input.
All GET and POST values are validated.
Only the request which is expected, is handled. So, when expecting a GET request the script will reject an POST request and visa versa.
Input values needed to query the database are carefully inspected for any form of SQL injection.

Does this sound as a good start?

Definitely. I'm wondering if you use available PHP libraries, a framework like say Suhosin and mod_security or if that all hinges on your own skills? Just being curious.

Quote:

Originally Posted by abillionwishes

At the moment I'm logging all kind of things. Do you have a good link on this subject?

There really is a lot to say about the subject and I think the most important things to understand, generally speaking, are that 0) maintaining a consistently good security posture requires constant attention and adjusting, that 1) you can't audit for what you don't log, that 2) Linux doesn't come with extensive auditing enabled out-of-the-box and that 3) successful auditing isn't confined to flicking one switch in one central application. Knowing which logging mechanisms your distribution installs by default (.*syslog.*, PAM, AppArmor, firewall, sudo) what logging (facility.priority) they do by default, how user logins and applications (errors) get logged helps. By restricting user logins, users access to (root-owned) resources and network access you create your first line of defense and that's why hardening the OS is so important before moving on to your attack surface (network-accessible services). Check out the logging section in http://rkhunter.wiki.sourceforge.net/SECREF?f=print ?