Debian Administration

I can help you with testing for CONFIG_NETFILTER :

grep CONFIG_NETFILTER=y /boot/config-$(uname -r)

If the above command returns 'CONFIG_NETFILTER=y', you're all set.

You ask lots of good questions, and I'm sure you'll receive some useful comments here.

With regards to CONFIG_NETFILTER I'm certain that will be enabled, so I'll ignore that. For getting a firewall to survive reboot we did have some previous discussion on the topic.

Personally I create a shell script in the directory /etc/network/if-up.d/ - every executable file in that directory will be executed after the network interface(s) have been brought up.

So I have a simple firewall there:

#!/bin/sh

# clear existing rules
iptables --flush
iptables --delete-chain

# Set default policies for all three default chains
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

# Enable free use of loopback interfaces
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# now allowing incoming http, ssh, and stmp
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -s 0.0.0.0/0 -j ACCEPT
iptables -A INPUT -p tcp --dport 25 -m state --state NEW -s 0.0.0.0/0 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -s 0.0.0.0/0 -j ACCEPT

# and now outgoing: dns + smtp
iptables -I OUTPUT 1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p tcp --dport 25 -m state --state NEW -j ACCEPT

Running this will setup rules, testing it is a matter of trying to connect remotely when you should/shouldn't be able to and seeing if it succeeds. (A tip: When working with a firewall for the first time add a cron-job to clear all your rules every 30 minutes - that way if you get locked out you're not lost!

Regarding tripwire it is later than ideal, but if you're certain you're not already compromised you may add it.

Pam configuration? We've talked about it before - honestly? I don't see what you need to mess with it for here.

Steve

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.

On http://www.debian.org/security/crossreferences you can look up the CVE numbers that ScanAlert hopefully referred to.

And I have to agree with a few of the others: Install a proper firewall, like Shorewall for example. SOOOOO much simpler to understand and maintain than Netfilter low level stuff.

Good luck!
/MBL

Hi,

I am currently developing a PCI compliant, middleware and back-end tiers (including repository) for a major currency exchange company. In order to comply with PCI rulings, here in the UK, the following business (and PCI) rules have been applied:

. No Credit Card Numbers or CV2 Numbers are stored, ever!
. The BINS, length and last 4 characters of the CC Number are stored.
. Single transactions including CC Number and CV2 are encrypted and transmitted, to the clearers, using https 443
. CC Numbers and CV2 numbers are not to be stored on site in any form, either on paper or elecronically. i.e. email or database

Follow these rules and you can't go wrong and even if you have a security breach as you can't 'leak' what you don't have.

Regards
Nick Adie
Consultant Developer

I thought that PCI was a bus standard. The PCI website that you linked to does a great job of not explaining what they think PCI actually stands for....

My few limited attempts at e-commerce have always used a third-party payment processor, so the card numbers and other sensitive data doesn't pass through my server at all (e.g. worldpay, paypal). You might consider this if making your own server sufficiently secure is too much work.

I normally take the word "firewall" to mean "hardware firewall", unless they explicitly say that a software firewall is acceptable. Would other people agree with me? If a software firewall is acceptable, here's what I've done on my web server:

My first attempt used the "guarddog" program. This is a nice GUI that lets you set up the rules. Eventually I got around to learning how to do it manually; this was mainly based on reading the iptables man page. I wrote a script, which is only about 50 lines, and put it in /etc/rc.firewall; this is called from /etc/init.d/firewall. I think this setup is based on how guarddog did it.

> QUESTION: But how do I determine if the CONFIG_NETFILTER option is set?

It probably is set; if it's not you'll get an error later.

> QUESTION: But where do I install my firewall script?

I've described how mine is done above. It doesn't really matter.

> How do I test it?

By trying to connect to ports that you have blocked, and seeing if you get in.

I hesitate to say this, but those questions are rather basic. Securing credit-card numbers is important. Maybe you should get some more experience of practical security on a less-critical system first?

Thanks all for your terrific information.

Lloyd

As far as IDS, I've found ossec to be very easy to use and set up, though I've never used it in a commercial setting. Ossec also has a web interface to allow easy monitoring and the ability to act as an IPS if you wish.