You are not currently logged in. If you do not have a user account then please consider creating one and logging in before you post your comment. This will allow you to track replies to your comment, and take part in the site much more freely.

To add your comment, fill in all the boxes below and then preview it to make sure you're happy with the way that it looks.

This is the comment you were replying to, attached to the article Struggling to implement PCI compliance:

#4 Re: Struggling to implement PCI compliance Posted by stevenothing (85.158.xx.xx) on Fri 14 Mar 2008 at 11:58 When I've done this in the past, I've used a dedicated machine for the website, and another dedicated machine for the firewall (and ideally, separate one for the DB, IPs, etc., but that's not always practical). For persistent firewall rules, I really like shorewall. I've also found it much easier to read configs than raw iptables scripts (even well written ones), and maintaining your firewall is at least as important as the initial configuration. For password policy, we wound up using kerberos, because the company we were dealing with had some quite convoluted rules regarding password re-use and expiry, which we couldn't easily do with pam. If you just want to expire passwords regularly, you can do this with shadow. Make sure root's password doesn't expire, or your cron jobs will stop working. IDS is a tricky one. Tripwire is a bit of a pain to install, and update, and tweak. It encrypts its database too, which is nice. Does get frustrating typing your passphrase in every time you want to update it, though. It's recommended that you keep your databases off-server, or in hardcopy, but that's not something I've ever done. Also don't get too enthusiastic when telling it what to monitor - this quickly becomes a pain and you'll just wind up ignoring your "file has changed" emails, which makes the whole system useless. I'd stick to something minimal, like binary directories. The default install, last time I did it on Debian, tried to monitor /dev, so you'd get alerts about /dev/pty/'s having changed. It's not impossible to install tripwire on an existing system. You'll just have a bit more work to do ensuring that all of the files it is including in its database are real, and they should be there. debsums can help a little, here. Aide is also worth considering. It doesn't (or at least didn't last time I checked) do the database encryption that tripwire does, making it easier for an intruder to hide his steps if you don't have offsite copies of your database), but I found it much easier to work with. For network intrusion detection, snort is the best choice. The main problems with it are that you need to get decent baselines so that you can tell it what to ignore. It will then proceed to send you so many emails that you'll ignore them anyway. Using snort with a MySQL backend, and something like ACID can help make it a bit more manageable. If you're doing this for someone else, it's worth trying to find out of they have a security person, or can appoint someone, to check snort/tripwire emails. This way it becomes someone else's problem. mod-security for apache can be useful too, especially if you're only running a single application, which you control, and don't need to worry about angry messages from users complaining that someone couldn't post "wget%20" to their php forum. I usually tell it not to block anything, and just rely on its audit log to help track down the buggy bit of code that's let some malicious user on to a server. Because of the vagueness of the PCI definition, a lot of the work is simply documentation and trying to prove that you've met the requirements. If this is an important project then it's worth getting an external auditing company in to take a look, as they'll be able to tell you exactly what to do. Beware of companies that will just give you a Nessus-generated PDF and charge you a few thousand for the privilege.

Inappropriate comments will be removed.

Username:

Password:

[ Advanced Login ]

Register Account