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

[jennyw]

My first question would be: What's your budget? ;-)

On Mon, Apr 01, 2002 at 09:25:14PM -0500, Raven, corporate courtesan wrote:
> Heya --
> 
> Quoth Kai MacTane (Mon, Apr 01, 2002 at 03:08:40PM -0800):
> > Personally, I'd rather use 1.2.3.0/24, if we're going to claim it's 
> > routable. But okay.
> 
> 	Feel free to use that if it makes you more comfortable.  I was
> just aiming for something that wasn't anyone else's IP space.
> 1.2.3.0/24 is a fine choice for that purpose.

Yeah, 1.2.3.0/24 or a.b.c.0/24 make it a little less confusing since we 
may suggest they use non-routable IPs internally.

> > >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.
> 
> 	Yep -- it's partially because I'm mean, and partially because
> that's the sort of thing you see all the time in real networks.  The
> majority of the networks I've seen have been around for a while, and
> weren't designed to grow gracefully.  So there are IP allocation schemes
> that don't make any sense, things that were done for some reason that
> nobody remembers but "have to be that way", and designs that were top of
> the line -- twenty years ago.

I suppose this might mean that there may be some services running on some 
machines that depend on those IPs being the way they are ... I guess 
before renumbering, I'd suggest figuring out what's going on on the 
network.  Maybe by sniffing traffic destined/coming from those servers? 
Unless management there is okay with just making the change and fixing 
things later.  But if you did it the longer way you could probably do this 
with minimal service interruptions.

> 	Feel free to advise your client to renumber, but you may want to
> see what sort of a business they're running first.  (Renumbering for a
> small business where the main users of the servers are your employees is
> a lot less painful than renumbering if your customers also use those
> servers.  Renumbering your customer-facing boxes when you're an ISP is
> awful.)

Renumbering customer-facing IP addresses probably wouldn't be necessary if
you have your own CIDR block. You could use one-to-one NAT from the old
addresses to the new addresses.  Additionally, since clients are relying
on DNS, changing the external numbers wouldn't be too bad, either -- DNS
could resolve to the new addresses while the old addresses would still
work for a while. I would make as few changes as possible at any given 
time. Completely redoing everything at once is asking for trouble. So a 
firewall with the simplest yet valuable ruleset first.

> > >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>
> 
> 	That was another one I left intentionally vague.  [grin]  It's
> the type of thing that many clients say.  They often don't know a thing
> about ports and servers that listen on them.  

I'd suggest initially setting up a firewall that allows all outgoing
traffic from the internal network and logging everything so we figure out
what's going out.  Incoming traffic: 53 to DNS server, 25 to SMTP server,
and 80 to Web server. If users need to check POP or IMAP, then we could do
that, too, although I'd hope this wouldn't be needed.  We can add more 
rules after this first one works.  I suspect that some of the Windows 
folks are used to using AOL and IM programs.

Eventually, though, it would be nice to give them access over https Web 
mail and/or SSL IMAP/POP instead of cleartext.  In any case, I'd want 
passwords changed as we do this, since some of them may have been sent in 
the clear before.  If they are identical to ssh passwords, we really have 
a problem, firewall or no ...

> 	I didn't give the IPs of the workstations -- assume they were
> just picked at random and statically assigned from unused addys in their
> netblock.  So all the workstations currently have routable IPs.

Another reason to leave the IPs alone for now. After the firewall is 
setup, we can work on the addressing scheme (don't want to spend a 
lot of time planning addresses, which can be really hard, when we 
could put up a firewall right away and deal with this later). 

I would suggest that all workstations should eventually be DHCP clients.  
For people wanting to ssh into their machines, we could either reserve IPs
based on MACs or setup dynamic DNS. Servers would have static IPs.

Reasons for renumbering using non-routable addresses:

1. Extra layer of protection.
2. Easier (i.e. less expensive) to manage as network grows.
3. Easier to change ISPs (unless you own your own block of routable 
addresses).

> > First off, these people want a DMZ.
> 
> 	Good.  Once you explain what that is, they agree that it sounds
> like a good idea, since they have servers that they do want to allow
> external access to, and workstations that they don't.

The budget works its way in here. A single firewall computer with multiple 
NICs or two firewalls?

> > 3) How long do you expect this system to remain in place before a
> > redesign?
> 
> 	They say, "Why would we need to redesign?  We're designing now.
> That's what you're here for."  [grin]

DHCP comes into play here.  I worked at a company that used static IPs and 
ran out my first week or so of work.  And I'd never used Checkpoint 
before then.  That was a lot of fun.  But I guess that's one way to learn! 
;-)

> 	Yep.  Another reason to document well, too.  I've seen so many
> cases where a "quick patch" was the de facto standard for years.

Yeah. Documentation is important. So is a fallback plan in case you (the 
consultant) get hit by a bus or something.  It'd be good to identify 
people they could follow up with. Maybe even find someone at the company 
to train.

> ISP -- Cust Router -- Cust FW1 -- Cust DMZ -- Cust FW2 -- Cust Winboxes
> 
> So the ISP has assigned the IPs for the link between them and the
> customer router, and the Ethernet address on the customer router is
> usually the first assignable one in the block.
> 
> 	If I were you, I'd let the router interface be 10.1.1.1 and take
> 10.1.1.2 for the outer interface of my first firewall, and 10.1.1.3 for
> the inner interface of the first firewall.  But there's no reason it
> *has* to be like that, it's just easier to remember.

Wouldn't that require some pretty weird subnet masks? I'm not entirely 
sure that's even possible.  I guess I would have used 192.168.x subnets 
for each subnet in between routers/firewalls. This is also useful in case 
you want to stick something else in those subnets (an IDS, for example).

> > 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.)
> 
> 	I'd put it on the file server, myself.  I prefer to keep as few
> other services as possible running on the firewalls.

Yes, I'd prefer that it didn't live on the firewall, too.

> > 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
> 
> 	Assume that they do.
>  
> > 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
> 
> 	One important thing about firewalling -- order matters!  So if
> there was a packet that claimed to be from 10.1.1.72 going to 10.1.1.14
> port 80, it would already have been let through by your earlier rule of 
> 
> ipchains -A input -p tcp -d 10.1.1.14 80 -j ACCEPT
> 
> and so would not be denied and logged here.  It's generally a good idea
> to put your martian-catching rules at the beginning of your ruleset, so
> that this sort of thing doesn't happen.  But other than the order, the
> rule is fine.  ("Martians" is an industry term for packets that
> shouldn't be.) 
> 
> > 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!)
> 
> 	Good idea.  They want them to be denied.
> 
> 	Also, consider what you'd want to do with ICMP packets, both
> incoming and outgoing.  Since you didn't specify what to do with them in
> your ruleset, they'd all get dropped.  I don't think that's what you
> want.

Is there a really good reason to allow ICMP packets incoming?  I can see 
outgoing, but I'm not entirely sure about incoming. Maybe to the servers.

> 	Ah -- that's the difference between ipchains and iptables, right
> there.  There is no such rule in ipchains, because in order to keep
> track of responses, you need a stateful firewall.
> 
> 	Instead, we are forced to use the ugly workaround of allowing
> all high ports (above 1024) through the firewall to machines that would
> be using client software.  This, obviously, is less than optimal.  It
> makes the default deny policy really hard to enforce, because you can't
> predict what high ports will need to be used in a client connection.

In this case, you definitely want to log all traffic. pcANYWHERE and other 
nice things live in high ports. I'm amazed at how often I seep pcA loaded 
on machines and running.

> 	So here, you have three options.  One -- reverse your ruleset,
> use default-accept instead, block all low-port services to any box that
> doesn't use them, and block specific high ports that you wish to
> disallow (31337, 12345, 27655, things like that).  Two -- put all your
> workstations, Linux or Windows, behind the second masquerading firewall.
> Three -- use iptables instead so you can actually do stateful
> firewalling.

Sounds like a good reason to use iptables ...

> 	Keep in mind that the servers may need to communicate with
> external machines on high ports as well, if they're acting as any sort
> of client.  (If you get a new version of SSH to your Web server via FTP,
> that Web server needs to be able to communicate like an FTP client and
> use those high ports.)
> 
> > 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.
> 
> 	Nope, that's it.  IP masquerading is frighteningly easy,
> assuming that the right options are turned on in the kernel.  The only
> thing you need to make sure of here is that your outer firewall isn't
> blocking high-port packets that the Windows workstations behind the
> second firewall need.  

How about ssh'ing to workstations? Those will need to be on a separate, 
non IPmasq subnet, right?  Or can you write a rule that will 
statically map them and except them from ipmasq? I should probably 
read about this ... Nonetheless, I think it's a good idea to wait to do 
any form of NAT until the outer firewall is setup and working.

Jen