[Courses] [Security] Firewalls: Ipchains syntax and implementation

[Kai MacTane]

At 3/29/02 06:36 PM , Raven, corporate courtesan wrote:
>         There is an excellent how-to that explains the rules of ipchains
>firewalling at:
>
>http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html
>
>I could go over the syntax (and will if anyone wants me to), but feel
>like I'd be reinventing the wheel since I think Rusty's done such a
>good, clear job of it already.

Right about here was where I was thinking, "Yeah, he explains the syntax, 
but to really learn any grammar, you need actual practice with creating 
"sentences" (in this case, rulesets) of your own. (And reading the work of 
others.)"

I see you were already ahead of me on that... <g>

>         So let's try to apply all this knowledge.  You are a security
>consultant hired by the admin of example.com's network.  You have the
>(we'll pretend that it's routable) IP block 10.1.1.0/24.

Personally, I'd rather use 1.2.3.0/24, if we're going to claim it's 
routable. But okay.

>Most of your network is comprised of Windows workstation boxes.  You also 
>have some Linux workstation boxes, an FTP server running under Solaris at
>10.1.1.7, a Web server running under Linux at 10.1.1.14, and a file
>server for the Windows machines at 10.1.1.21.  Your mail server is
>hosted on the same machine as your Web server (10.1.1.14).  DNS is
>handled by a FreeBSD server at 10.1.1.5.

Is there any rhyme or reason to these IPs? They're so... weirdly 
non-contiguous.

>Your Windows users want to be able to "access the Internet".

A sensible desire, and its very vagueness tells me what I need to know. <g>

>Your Linux users want to be able to ssh into their workstations from
>home so that they can work remotely.

Gotcha. We don't seem to have IPs on those workstations, but I'll probably 
be assigning them to a particular slice of the address-space anyway, for 
convenience.

>What sort of a setup would you recommend?  What further
>questions would you have for your employers?  And what firewall
>ruleset(s) would you propose?

First off, these people want a DMZ. (They may not think so at first, but 
they obviously hired me to give them advice. I advise them that a DMZ is 
what they want. Presumably, they value my opinion (since they're paying me 
X dollars an hour for it) and they take my advice.)

The Windows boxes don't get Internet-routable IPs. If there aren't many of 
them, and not much expansion is likely, they go on a 192.168 Class C-sized 
(or /24-sized) subnet. If there are more, or expansion is likely, they'll 
go into a larger (say, /16-sized) subnet. (If the client has more than 
60,000 Windows workstations, then let's be real: they didn't come to me, 
they hired an entire consulting *firm*.)

So that's one set of questions I have for the client already:

1) How many Windows workstations do you currently have?
2) What's your growth rate like? (Ideally, I'd like to see a curve
    over time, so I have some idea if we're about to hit an asymptotic
    point or something. Failing that, just "How many people did you hire
    in the past year?" will probably do for estimates.)
3) How long do you expect this system to remain in place before a
    redesign?

Note that I *don't* take the client's word for it on #3. I double or even 
triple it, because I remember that none of the COBOL programmers who used 
all those 2-digit date fields back in the '70s believed that their software 
would still be in service for Y2K. (One of the main lessons of Y2K: Expect 
whatever you implement to stay in service *far* longer than you think it 
should.)

So, honestly, I'm probably going to be assigning those into either the 
192.168.0.0/24 space (if it's a small company that looks like it's not 
going to grow past 250 Windows workstations in, say, the next five years), 
or into 10.0.0/16 if they have lots of Windows machines (or if it looks 
like they might have them in the near future). This is why I was a little 
weirded out by treating 10.1.1.0/24 as routable earlier. So, for the rest 
of my response, I'll assume they're a company of only 25 people, and they 
seem to add about 5 people per year. They go in 192.168.

The file server for those Windows machines will also go in the 192.168 
address space. (Unless there's some reason it needs to be accessible by 
anyone or anything other than the Windows boxen? There's nothing about that 
so far in the spec... Presuming that nobody else needs to access it, it 
goes off in the private subnet. Its IP address changes; oh, well.)

One machine goes on 10.1.1.0, and becomes the gateway for everything else 
in the company. It's the outer firewall. It lets pretty much anything pass 
outbound, since I see no reason to restrict the company's ability to send 
anything they want. One exception: as a means of last-ditch intrusion 
detection, we could set it to log any outgoing packets with a source 
address outside the 10.1.1.0/24 range. (Then again, I think this wouldn't 
so much notice a situation where someone else had cracked the example.com 
network, but rather a case where an example.com employee was trying to 
crack someplace else. Still, not that hard or that bad an idea to log.)

Inbound is, of course, a much more restrictive story. It should allow ssh 
to anywhere, and any kind of reply packets (like the usual NAT/ipmasq 
firewall -- this should allow the workstations, even behind the second 
firewall, to initiate any kind of connection they need to). Other than 
that, I think the only things it should allow inbound are:

* port 53 (tcp and udp) to 10.1.1.5 (DNS)
* port 80 (and possibly 443?) to 10.1.1.14 (HTTP and HTTPS)
* ports 25 and (I presume) 110 (and maybe 143?) to 10.1.1.14 (SMTP,
   POP3, and IMAP, respectively)
* ports 20 and 21 to 10.1.1.7 (FTP-data and FTP)
* port 22 to 10.1.1.0/24, _except_ to the second firewall machine (SSH)

I have yet to choose an IP for that second firewall. I tell you what: I'm 
going to arbitrarily decide that example.com doesn't need more than about 
30 server machines, and hasn't got more than about 50 or so Linux 
workstations. So 10.1.1.0/27 (10.1.1.0-31) is set aside for servers, and 
10.1.1.32/26 (10.1.1.32-96) will be set aside for the Linux workstations.

If example.com's growth rate doesn't support these particular numbers, I'll 
set the boundaries in other places, of course. But these make nice example 
numbers and netmasks.

Finally, I'll plonk the second firewall down on 10.1.1.128. And so that 
final, SSH rule, turns into:

* port 22 to 10.1.1.0/25 (SSH)

, thus allowing SSH to 10.1.1.0-127. If someone needs to administer the 
second firewall remotely, they have to do that by SSHing to one of the 
other Linux boxes, and then relaying from there. (I talk to the client 
about this -- if they have a real problem with it, I try to point out to 
them that the security benefits *should* outweigh the convenience 
drawbacks, since they shouldn't need to tweak either firewall all that much 
once things are done.)

Also, the outer firewall should log any inbound packets claiming to be from 
10.1.1.0/24. There may be other stuff it should log as suspicious, but I 
can't think of what at the moment, besides SYN floods.

The second firewall, OTOH, has a much more restrictive ruleset. It 
masquerades the 192.168.1.0/24 subnet, and may (read: probably should) run 
dhcpd servicing said subnet (only listening on the internal interface). 
(Alternatively, that DHCP server can run on the file server machine.) It 
basically allows any outbound traffic (and, once again, may well log stuff 
going outbound with a bogus source address), and lets nothing in except 
replies to outbound packets.

Now, let's see if I can come up with the right ipchains rules to make all 
this happen... On both firewalls, I'm considering eth0 the "outer" 
interface, and eth1 the "inner" one.

On the outer firewall:

Set default input policy to drop packets on the floor:

ipchains -P input DENY

Allow the various services to the various server machines:
ipchains -A input -p tcp -d 10.1.1.14 80 -j ACCEPT
ipchains -A input -p tcp -d 10.1.1.14 25 -j ACCEPT
ipchains -A input -p tcp -d 10.1.1.14 110 -j ACCEPT
ipchains -A input -p tcp -d 10.1.1.7 20 -j ACCEPT
ipchains -A input -p tcp -d 10.1.1.7 21 -j ACCEPT
ipchains -A input -d 10.1.1.5 53 -j ACCEPT

And if they want HTTPS and IMAP, add these:

ipchains -A input -p tcp -d 10.1.1.14 443 -j ACCEPT
ipchains -A input -p tcp -d 10.1.1.14 143 -j ACCEPT

Now allow SSH to the Linux section of the DMZ:

ipchains -A input -p tcp -d 10.1.1.0/25 22 -j ACCEPT

Log packets claiming to be from our own IP space arriving from the outside:

ipchains -A -i eth0 -s 10.1.1.0/24 --log -j DENY

And log ones going out that claim to be from somewhere else:

ipchains -A -i eth1 -s ! 10.1.1.0/24 --log -j DENY

(I might do that last one with a "-j ACCEPT" instead, if I want to be 
really sneaky. Before setting that rule, I definitely consult with the 
client on what they want!)

I think the only thing missing now is the rule that allows responses to 
come back unimpeded. I'm having a little trouble figuring that one out at 
the moment, as I look at the ipchains man page. (Which is part of why I'm 
taking this course, rather than teaching it!)


Now, the second (inner) firewall... I think this one can basically just 
grab the kinds of rules you can find in Rusty's ipchains HOWTO, at 
http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO-3.html:

ipchains -P forward DENY
ipchains -A forward -i eth0 -j MASQ

And I'm not sure it needs anything else.

I *am* reasonably sure, however, that I've forgotten something crucial in 
at least one or two places. I don't have enough machines around right now 
to set up an equivalent test network and check these, but I suspect that 
something's FUBARed here in a way that will make at least one of these 
network segments totally unable to talk to the other(s), and that it could 
all be fixed by the addition of just one or two rules somewhere.

>We will assume for the purposes of this
>discussion that the Linux boxes you're using are already built, that
>firewalling and IP masquerading support are already built into the
>kernel, and that the Linux boxes have been stripped of unnecessary
>services and locked down.

"Assuming" is always a bad idea, but especially so in security. Just to be 
certain, I portscan all the Linux workstations. As I see it, no port <1024 
should be open except ssh. (High-numbered ports will, of course, need to be 
reachable in order for various network services, like Web browsers, to work.)

Heck, since it's not really that difficult, I also portscan the server 
machines. Just in case.

Somewhere along the way, just for completeness' sake in this answer, I do 
tell the folks at example.com that they should set their Windows FTP 
clients to use passive mode if they experience any troubles. (Assuming 
they're using any.)

>Post your ideas and rules to the list, and we'll discuss them and see what 
>the best setup we can come up with is for example.com.

Since my current setup probably doesn't provide even basic functionality, I 
doubt it's the best. <g>

                                                 --Kai MacTane
----------------------------------------------------------------------
"When nothing's sacred any more,
  When the demon's knocking on your door,
  You're still staring down at the floor."
                                                 --The Chameleons UK,
                                                  "Swamp Thing"