Hey Amos, thanks for that. And also thanks to Daniel and Sonia. Cheers, Daniel
2009/11/10 Amos Shapira <amos.shap...@gmail.com> > 2009/11/2 Daniel Bush <dlb.id...@gmail.com>: > > I was following Rick's recent post about penetration testing with some > > interest. I'm looking at complying with anz e-gate for e-commerce > > transactions. ANZ has this declaration form for internet sites that you > > have to sign. One of the tick boxes says "Do you operate a firewall that > is > > regularly updated?" > > I'm a bit late in the party but still wanted to add my two cents if that's > OK. > > Some relevant points I learned during the PCI DSS compliance process > we've gone through: > > 1. "They" also care not just about preventing people getting > unauthorised access to your server but also in making it difficult to > get data out (e.g. by someone with an "inside knowledge"). So firewall > rules should also limit outgoing connections to specific hosts. E.g. > you want to talk to specific, hopefully more trusted, DNS and NTP > servers, specific upstream SMTP servers (instead of allowing access to > just about any SMTP server in the world) and maybe specific yum update > servers, but not more. Since rules could be added to allow you > temporary access outside for specific tasks, it might be prudent to > verify once in a while that they are back to the way you expect them > to be. > > 2. Application firewalls can add a lot to the simple "block everything > except ports 80 and 443" iptables. I'm talking about mod_security and > having its rules updated regularly to catch attempts to exploit holes > in known application as they get discovered (e.g. > http://www.gotroot.com/tiki-index.php?page=mod_security+rules). > > 3. "They" care about auditing and accountability - the rule of thumb > is "no shared accounts" - if there are more than one users on the > system then each should use their own account and "sudo ..." for each > privileged command. It also makes it easier to track who did what and > when (bash HISTTIMEFORMAT='%F %T ' is also very useful, not just for > "Them"). > > 4. SE Linux is a major headache, I seem to be in the mainstream by > disabling it for now. But it appears that once you get to learn it and > tweak it properly it can add a lot to the security on your server and > limit the damage done by a potential cracker. e.g. allow HTTP access > to the yum servers only by the yum process, or send mail only from > specific programs/scripts. The best tutorial I found about SE Linux so > far resides in http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/ > (I still have to finish reading it) > > In general - you can look at this as "ah yeh, the security lawyers and > paper pushers are at it again" but I found that giving attention to > these requirements and the thinking behind them makes a lot of > security sense (most times - anti-virus for purely linux environment > is pretty useless from what I've researched so far) and should end up > in more secure servers. > > Cheers, > > --Amos > -- Daniel Bush -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
