Re: [SLUG] advice on security compliance
Hey Amos, thanks for that. And also thanks to Daniel and Sonia. Cheers, Daniel 2009/11/10 Amos Shapira > 2009/11/2 Daniel Bush : > > 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
Re: [SLUG] advice on security compliance
2009/11/2 Daniel Bush : > 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 -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] advice on security compliance
On Mon, 2 Nov 2009 16:28:25 +1100, "Daniel Bush" said: > have to sign. One of the tick boxes says "Do you operate a firewall that > is > regularly updated?" > > I have an iptables firewall which basically blocks all ip6 and all ip4 > except for a couple of ports I expose to the internet. I don't see why I > need to update it "regularly". It's just a standard security checklist for Windoze blinkered admins - say 'yes'. And you do update your firewall regularly, via 'sudo apt-get update' (or similar) :-) -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] advice on security compliance
Daniel Bush writes: > 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?" Oh, gawd. PCI compliance. I /hope/ you get to stay at the lowest level of compliance, where they mostly never audit, and don't have to deal with any of the higher bits. > I have an iptables firewall which basically blocks all ip6 and all ip4 > except for a couple of ports I expose to the internet. I don't see why I > need to update it "regularly". Why, because otherwise your system will not be up-to-date to protect you against the latest exploit for the underlying Windows OS, or to handle the latest threats! In seriousness: what they mean, basically, is "do you actually pay attention to your firewall", and you can ignore the theoretical "regular updates" part unless an auditor tells you otherwise. (Which, with luck, they won't, because you will get an auditor who isn't an idiot in the fairly unlikely event that ANZ or their PCI auditing firm decide that you do qualify for one. Most auditors are not stupid, in my experience.) > Do people use any additional application-level filtering on top of iptables > packet filtering for ssh or http (aside from any security configurations > that these services already provide) ? (The services I'm exposing through > iptables are ssh and http. ) > > If not, how do you deal with a compliance item that makes dubious sense and, > if you answered it honestly, makes you look bad when you're not? Read for meaning, answer to that. The PCI stuff is crazy: it has a bunch of Windows-like assumptions baked in, because many of their big clients use Windows. > The other thought I had was that it could be they are conflating my > understanding of a what a "firewall" is with antivirus software. I wouldn't be entirely shocked; IIRC there was an explicit anti-virus checkbox in one of the PCI compliance checklists I was given. I addressed it by adding ClamAV to the Linux server running Apache, Perl and PHP code, where it can stay updated daily, and scan the disk every now and then. > If people (staff even) are uploading stuff via http then maybe I need to > scan such content to prevent my system acting as an agent for spreading > viral content. But that's heading out of firewall territory. You would think, eh? Daniel The worst part of the PCI stuff was the implication that the /need/ to ask these questions, so presumably someone, somewhere *didn't* bother... -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons Looking for work? Love Perl? In Melbourne, Australia? We are hiring. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] advice on security compliance
Rob, 2009/11/2 Robert Collins > On Mon, 2009-11-02 at 16:28 +1100, Daniel Bush wrote: > > 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 have an iptables firewall which basically blocks all ip6 and all ip4 > > except for a couple of ports I expose to the internet. I don't see why I > > need to update it "regularly". > > Two primary reasons: > - iptables is not bug free. Few and far between, but not empty-of-bugs. > I mean updating the rules you use to filter packets not maintaining the software that does the filtering. Is that what you mean here? Maybe that's what this tick box means. I didn't think of that. I just assumed they're were talking about the filtering rules... > - ip4 and ip6 are not 'finished'. Every now and then a new RFC or even > std is released, and you need to update your firewall and routing rules > accordingly. (e.g. the nonroutable address space changes over time, so > you need to update your rules accordingly). > Must still be missing something here Rob. I just block everything except for the services I run on the public interface (and stuff on the internal loopback interface / localhost). Why do I need to worry about non-routables? > > Even if those two points didn't matter, if you admin the firewall using > ssh, and sshd has a bug permitting remote compromise, you'd be remiss > not to update that. > > I think this is a software update issue. As before I'm wondering if that is what the tick box meant. What confuses me is that I would have that as a separate tick box in itself, something like "do you regularly patch/maintain security updates for your software, especially firewall and related security systems?" That is not the issue I thought the tick box was addressing. I may be reading you all wrong here though :( > So, its an important checkbox, and if you're not maintaining your > firewall, don't tick it! (Worse still, if you think deny-all + a couple > of permits == correctly setup firewall - you need about 15 rules I > think, for a _minimally_ conformant firewall [that is, not in violation > of parts of the IP stack]). Ok, now you're worrying me. For a simple set up where you have an isolated box running a webserver and ssh: I have a default drop policy on all tables; a catch-all drop rule that logs certain things; I have some stateful rules so that I can talk to the outside world and several open ports on specified interface for tcp protocol where I am exposing services to the outside world. If the default is to drop everything except a specific set of ports on a specific interface using a specific transport why do I have to twiddle with these rules? Surely the only area of concern is the established/related stateful rules Is that what you mean? Are you reviewing the stateful part of your packet filtering firewall every week because you're worried it could get spoofed or something? If so, what is your strategy here and does it result in some sort of regular update? Or do you have default policy of accept which means you have to worry about closing stuff down all the time? I've always assumed drop so I don't even want to begin to think about the alternative. > Keeping on top of the whole mess is what is > implied by 'regularly updated', not turning on some vendor software-sync > button and forgetting about it. > > hm; as per my above comments. I'm pretty paranoid about my firewall. -- 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
Re: [SLUG] advice on security compliance
On Mon, 2009-11-02 at 16:28 +1100, Daniel Bush wrote: > 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 have an iptables firewall which basically blocks all ip6 and all ip4 > except for a couple of ports I expose to the internet. I don't see why I > need to update it "regularly". Two primary reasons: - iptables is not bug free. Few and far between, but not empty-of-bugs. - ip4 and ip6 are not 'finished'. Every now and then a new RFC or even std is released, and you need to update your firewall and routing rules accordingly. (e.g. the nonroutable address space changes over time, so you need to update your rules accordingly). Even if those two points didn't matter, if you admin the firewall using ssh, and sshd has a bug permitting remote compromise, you'd be remiss not to update that. So, its an important checkbox, and if you're not maintaining your firewall, don't tick it! (Worse still, if you think deny-all + a couple of permits == correctly setup firewall - you need about 15 rules I think, for a _minimally_ conformant firewall [that is, not in violation of parts of the IP stack]). Keeping on top of the whole mess is what is implied by 'regularly updated', not turning on some vendor software-sync button and forgetting about it. -Rob signature.asc Description: This is a digitally signed message part -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] advice on security compliance
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 have an iptables firewall which basically blocks all ip6 and all ip4 except for a couple of ports I expose to the internet. I don't see why I need to update it "regularly". Do people use any additional application-level filtering on top of iptables packet filtering for ssh or http (aside from any security configurations that these services already provide) ? (The services I'm exposing through iptables are ssh and http. ) If not, how do you deal with a compliance item that makes dubious sense and, if you answered it honestly, makes you look bad when you're not? The other thought I had was that it could be they are conflating my understanding of a what a "firewall" is with antivirus software. If people (staff even) are uploading stuff via http then maybe I need to scan such content to prevent my system acting as an agent for spreading viral content. But that's heading out of firewall territory. Regards, -- 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
