Jeremy Chadwick wrote:
On Mon, Oct 06, 2008 at 09:34:46AM +0100, Matthew Seaman wrote:Jeremy Chadwick wrote:On Mon, Oct 06, 2008 at 08:19:09AM +0100, Matthew Seaman wrote:Jeremy Chadwick wrote:If you want a "magic solution", see blackhole(4).block drop all looks fairly magical to me. Stick that at the top of your ruleset as your default policy, add more specific rules beneath it to allow the traffic you do want to pass, and Robert is your Mother's Brother. No more floods of RST packets.This is incredibly draconian. :-) I was trying my best to remain realistic.It's no such thing. This is the recommended standard practice when designing firewalls: always start from the premise that all traffic will be dropped by default and add specific exceptions to allow the traffic you want. Trying to work the other way round is a recipe for disaster: 'allow everything, but block what is then shown to be deleterious' means that you're always playing catch-up as changes on your servers expose new attack vectors and as attackers discover and try to exploit those holes. Not recommended, unless you actually /like/ being paged in the wee small hours.What I mean by 'draconian': "block drop all" includes both incoming *and* outgoing traffic.
Well, yeah. But 'block drop in all' is pretty much just an optimised variant of
block drop all pass out alleven if you never write it out that way. You're just starting two steps into the process I was talking about.
I have absolutely no qualms with "block in all", but "block out all" is too unrealistic, depending greatly on what the purpose of the machine is. Any outbound sockets are going to be allocated dynamically (e.g. non-static port number), so there's no effective way to add pass rules for outbound traffic. Using uid/gid is not sufficient.
I often advocate using "block in all", "pass out all", and then adding specific "pass" rules for incoming traffic (e.g. an Internet request wishing to speak to BIND on port 53, Apache on 80/443, etc.). Like I said: I'm being realistic.
One man's realism is another's open proxy or information disclosure and having to deal with abuse complaints. Yes, in practice for someof the firewalls we manage the policy is 'all outgoing is allowed', but by no means the majority. Most of the time we do permit outgoing for some or all of these protocols: FTP(passive), SSH, SMTP, DNS, HTTP, NTP, HTTPS, RSYNC, CVSUP and frequently that's allowing outgoing to any unless there's a requirement to restrict things further.
We aren't concerned with writing filter rules that operate on the local port numbers here, but with the port numbers on the remote sites we're connecting to. As you say, local port numbers are unpredictable, but stateful firewall rules handle all that sort of thing easily,even for stateless (UDP) protocols like DNS. Not only that, but looking up a packet in the state table is generally quite a bit faster than having to traverse the whole rule set. At least, it is when using pf.
Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW
Description: OpenPGP digital signature