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

[Raven, corporate courtesan]

Heya --

Quoth Kai MacTane (Mon, Apr 01, 2002 at 03:08:40PM -0800):
> 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>

	[grin]  Well, I learn best by example.  So I figure the more
"show and tell" we do, and the more commands we give and such, the
better people will be able to look at their own systems and go, "Hey,
I could set this up!".

	The other neat thing about being familiar with ipchains and
iptables is that you can look at some of the tools that will
auto-configure them for you, and then look at the rulesets they came up
with afterwards to get a handle on how they work.
 
> 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.

> >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.

	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.)

	As it happens, this particular client is a widget maker.  Their
customers send mail to the mail server when they need to order widgets,
get DNS from the DNS server when they mail example.org or surf to
www.example.org, and access the Web page on the web server.  The FTP and
file server only need to be accessed by employees.  They're not thrilled
about the idea of renumbering, but will do so if you a) can guarantee a
cutover with very little downtime and b) think it's important.  After
all, you're much more of an expert than they are.  

> >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.  

> >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.

	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.
 
> 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.
 
> 1) How many Windows workstations do you currently have?

	Let's say, twenty.  (If there were lots, I'd have given you more
netblocks to play with.)

> 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.)

	Slow but steady.  Widgets were a bit of a niche market, but
since they've put up the website they've been getting gradually more
business.  Last year they hired three new employees.  They expect to
hire the same next year.  (These are excellent questions, by the way,
and something to consider when doing network design.)

> 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]
 
> (One of the main lessons of Y2K: Expect whatever you implement to stay
> in service *far* longer than you think it should.)

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

	Fair enough, and close to the scenario I had in mind.
 
> 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.)

	The Linux workstations need to access it, too.  All the
workstations in the company need to be able to get at the same files.
(Again, mean, but true to life.)
 
> One machine goes on 10.1.1.0, and becomes the gateway for everything else 
> in the company.

	Er -- surely you mean 10.1.1.1?  10.1.1.0 is the IP that
represents the entire /24 netblock.

> It's the outer firewall.

	Okay.  Are you assigning 10.1.1.1 to the outer interface or the
inner interface?  And what IP address for the other one?

	The usual setup in cases like this is:

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.

	Also, doing the outer firewall on the same machine as your
router is entirely possible.  (You can assume that the router is a Linux
box doing routing if this is what you choose to do.  That's for the
purposes of our example -- you can firewall on Ciscos, etc., too, but
this is a class about Linux.)   The outer address of your router is
assigned by your ISP, the inner address is 10.1.1.1.  You can change
that too, if you want to.
 
> 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.)

	Good catch!  By disallowing packets outbound that don't come
from your IP block, you greatly reduce people on your network spoofing
addresses to the world at large.  (10.1.1.153 could still pretend to be
10.1.1.4 if they wanted, but 10.1.1.153 couldn't pretend to be
209.48.42.237.)  If everyone did this, it would make security geeks'
lives easier.  You are less likely to get an angry call from your ISP's
abuse department.  Have a gold star.  [grin]

> 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).

	That sounds like a reasonable "access the internet".  [grin]
You might also want to disallow obviously forged packets inbound (things
that claim a source address in private space, or a source within your
own network.)

> 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.
 
> 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.
 
> 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!)

	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.

	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.

	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.  

> >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.

	Go you.  Assuming that you've gotten the client to sign off on
it (since I know you're in the US), they're pleased.  You don't find
anything untoward.  Since this network has been on the Internet
unfirewalled, this is an amazing miracle.  [grin]
 
> 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.)

	They do this.  If you left all the high ports open above, this
isn't necessary, but if you went for one of the other options, their
lives may be easier because of this.
 
> Since my current setup probably doesn't provide even basic functionality, I 
> doubt it's the best. <g>

	It was very good, though.  Very thorough, and you were checking
everything you could even when I said it was okay.  [grin]  The mistakes
you made are the ones *everyone* makes, and so were a great learning
tool.  Thanks for spending what was obviously a lot of time on this.

	So, given that feedback, what changes would you (or anyone else
here) make to the ruleset and setup?

Cheers,
Raven

"The reward for good work is more work."