4

We are using PHP,MySQL,SVN, and Apache. I want to know if I assume the local subnet trusted, and allow all ports on our subnet using iptables, then allow only port 80 as open to "anyone". If it is "good security" taking that the subnet is trusted as a premise. This is also assuming good PHP code etc, and that apache is configured correctly.

This is using CentOS 5.

Joshua Enfield
  • 3,454
  • 8
  • 42
  • 59

5 Answers5

4

No defiantly not. In fact port 80 is probably the most dangerous port you can open on a modern system. Also not having https:// (tcp 443) means all of your session id's are being leaked. Not using https is a clear violation of A3: "Broken authentication and session management" in the OWASP top 10 for 2010.

A good thing you can do to protect your self is to run a Web Application Firewall(WAF) like Mod_Secuirty. A WAF is is a very different from a "packet filter firewall" like iptables.

I also recommend running a vulnerability scan against your system such as Acunetix or wapiti. Make sure your system is regularly updated: yum upgrade. Run PhpSecInfo and configure your php.ini such that no RED appears. PHP's default config is horribly insecure, it has gotten better (disabling remote file includes and register_globals by default) but its still really bad.

Rook
  • 2,655
  • 6
  • 27
  • 35
  • Thank you for the very detailed precision answer. I take it your recommending leaving http: closed completely then, and opening 443 (https)? I am also assuming that running iptables with only port 443 open in combination with WAF is the ideal arrangement? Thank you again. – Joshua Enfield Apr 07 '10 at 23:32
  • 1
    Thanks, i'm happy to help. You should leave port 80 open purely to redirect people to https://, you can take care of this in your Apache virtual host config file. – Rook Apr 07 '10 at 23:35
3

I would actually say the problem lies in:

"Assuming good PHP Code."

You can't take this for granted. Ideally, that server will go in a DMZ where the LAN can access it, but the DMZ can't access the LAN. The idea is that you assume your public facing server will get compromised, and then you want to limit the damage. By having a separate firewall between your LAN and the DMZ you likely limit the damage. So with a DMZ setup, subversion is probably not going to be on the public facing server. If you can't afford this extra server, creating a virtual machine and having the public facing server in that might be a sort of poor man's DMZ.

I also would take the extra step to only open up the ports to the local subnet that are needed (You probably need to trust you LAN more, but still limit it if you can). It probably won't be that many if you are using the state module (redhat/centos default setup).

Also, don't forget about security updates for the OS and applications.

Kyle Brandt
  • 83,619
  • 74
  • 305
  • 448
1

If everything is secure, then you have enough security. Unfortunately the first part of that sentence is rarely true. Open only the ports that are required, even to a trusted network.

Ignacio Vazquez-Abrams
  • 45,939
  • 6
  • 79
  • 84
1

well.. do not just limit incoming connections. filter outgoing too. and filter them both locally on OUTPUT table but also on router.

there are so many holes in popular scripts... minimize the casualties in case your server gets owned.

allow outgoing ESTABLISHED,RELATED [obviously], probably to few hosts with OS updates, maybe to your smtp relay server... and that's it. so you prevent box from downloading malicious payload, spreading spam etc.

pQd
  • 29,981
  • 6
  • 66
  • 109
1

I concur with @The Rook on this - the real danger is all that big fat functionality lurking behind 80. If you are writing web app code, regardless of language, I would hastily recommend you learn quickly how to write secure code and create secure designs. No amount of firewall defense will protect you from a crappy web app.