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

[Raven, corporate courtesan]

Heya --

	Back from Rubi-Con, y'all, and slowly wading through a kazillion
e-mail messages.  [grin]

Quoth Kai MacTane (Thu, Apr 04, 2002 at 01:44:05PM -0800):
> It actually *does* make me somewhat uncomfortable to use a non-routable IP 
> space as if it were routable. (I'm just as bothered by people setting up 
> their private, unconnected nets using IPs that would be routable. Partly 
> because I suspect that any random Ethernet might get connected to the 
> Internet at any time... then you suddenly go, "Why am I getting email for 
> some-random-organization.foo? Oh, *that's* who owns 123.45.67.0!")

	Yep -- I worked at a company that happened to.  There were
threats of a lawsuit when we found out our IP space had been so
gracelessly hijacked.  It takes permissive acceptance of routes being
advertised to the ISP from customers, but that's by no means uncommon.  

> I probably ask them at some point if they *want* to renumber while
> we're messing around with their network (i.e., if they have such a
> desire, this would be a great time). If they aren't, then I'm fine
> with that. (Although that FTP server is likely to get moved anyway.)

	Aside from the FTP server, they're fine with not renumbering.
 
> Good. I'm always pleased by signs that clients aren't morons.

	Heh.  Yeah.  I don't mind working for people who aren't
necessarily super-informed of every technical concern.  I do mind
it when they refuse to become informed before making important
decisions, or just dismissing technical considerations because "that's
too hard".

[re: the file server] 
> >         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.)
> 
> Oh, crap. Another fine assumption shot to hell. (Well, only partly an 
> assumption -- you did describe it as "a file server for the Windows 
> machines", not "a file server for the workstations". But I suppose I should 
> have double-checked before planning to make it inaccessible to the Linux 
> boxen.)

	This is another "because I'm mean".  Clients often give you
unclear or changing specs, and you have to ask the right questions to
figure out what they really want.  I figured hey, the truer to life, the
better.  (Please tell me if y'all would just prefer straight config
examples and none of the, er, real-world seasoning.) 

> I had been ignoring the customer router, and actually *had* explicitly (in 
> my own head) assumed that the firewall would act as the router. I mean, 
> since it's doing firewalling anyway, it certainly has the ability to be a 
> router, and I didn't really see the need to have two pieces of equipment 
> where one would do. 

	Sure, you can do that if you want.
 
> >         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.
> 
> Whoops, now I think I'm confused.

	Okay -- let me try to rephrase.

	You've got (at least) two links here that you're dealing with.
When you're assigning IP addresses, it's often easy to assign a /30
(four IPs -- the network IP, the two routable IPs, and the broadcast IP)
to each point to point link.  So at a minimum, you have 
         
ISP Router ----------- Customer Router ---------- Customer DMZ

Two links.  Usually, the IPs for the link between the ISP and the
customer router come from the ISP's block of IPs, and the IPs for the
link between the customer router and any other customer equipment come
from the customer's IP space.

	So usually, you'll get a /30 assigned from the ISP's netblock to
the link between you and them.  So the external interface on your router
(or your router/firewall, or whatever device you have there) will come
from the ISP's IP block.  For example:

   1.10.3.101     1.10.3.102       1.2.3.1    1.2.3.2, 1.2.3.3, etc.
ISP Router ----------- Customer Router ---------- Customer DMZ
           1.10.3.100/30               1.2.3.0/24
         from ISP IP block             from customer IP block

So if you want to have one device doing your routing and your outer
firewalling, its outer interface will likely have an IP assigned by your
ISP from its own routable netblock, and your internal interface will be
assigned (generally) the first IP of your own netblock, though really it
can be any IP of your own netblock.

	Now if you had wanted a different firewall from your router, you
would have essentially added another point to point link.

 1.10.3.101  1.10.3.102  1.2.3.1  1.2.3.2  1.2.3.5  1.2.3.6...
ISP Router ---- Customer Rtr ----- Customer FW ------- Cust DMZ
       1.10.3.100/30       1.2.3.0/30          1.2.3.4/30...
     from ISP IP block   from cust. IP block   from cust. IP block

By chopping off /30s from your /24 for the point to point links, you
lose the one large continuous block, and you have to make it into a
bunch of smaller subnets.  (You can adjust the size of those somewhat,
but it's still not as good as one big block.)  So by running both the
firewall and the router on one box, you conserve IP space and keep your
network IP allocation cleaner and easier to understand.

	Does that make sense of babble?  [grin]

> Yeah, after I'd sent my email, I decided the file server would be a much 
> better place for it.

	Okay, so now we have a file server/DHCP server behind the
second firewall.
 
> >         Assume that they do.
> 
> Then it's all set; just uncomment those rules.

	That's handy; it's very nice to be able to make changes by
commenting and uncommenting config files.  (After we get the network
topology, IP allocation, and firewall ruleset set up, I want to talk
about the scripts that start and stop the firewall, too.  Someone remind
me if I forget.)
 
> Personally, I don't much mind if someone pings my hosts and finds out that 
> they're up. If the client is really paranoid, I'll go through a table of 
> ICMP codes and figure out what to drop, but otherwise, I'll put
> 
> ipchains -A input -p icmp -j ACCEPT

	Something that you may not be aware of is that it's possible to
tunnel all sorts of things through ICMP.  Things like this are why it's
good to have a firewall that's relatively restrictive, without
inhibiting usability.

http://www.detached.net/icmptunnel/

If you want to accept ICMP at all, you're stuck with some vulnerability
to this.  (I personally feel that it's worth it; I like getting error
codes and not getting screwups from broken Path MTU discoveries.)  But
you can reduce it by limiting the ICMP that you accept.

http://www.tldp.org/HOWTO/mini/Firewall-Piercing/

will give a general idea of the sorts of things that people do to get
around firewalls and their rulesets.  Maintaining a firewall that
doesn't make your users miserable, it will be hard to catch all of
these.  This is another argument for host security and defense in depth.
Trusting only one component can get you, well, hacked.
 
> >         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.
> 
> Ick. For a client, I pick option number three. Since this piece of 
> coursework uses ipchains, that's not an option. <g> I think I reverse my 
> ruleset.

	Okay.  You can make it slightly better by rejecting all TCP
incoming to high ports that's not an established connection with
the --syn flag to deny any incoming syns to a high port, and then
accepting any TCP that's not a syn to the high ports.

> I'm honestly not sure it would occur to me to get the client to sign off on 
> this first, as I was planning on doing it from within their own network. 

	Even so, if you're in the US at least, it's better to make sure
you don't go to jail.

> It's not going to look like a hostile attack coming from somewhere else. 

	No, but if someone at the company decides to get outraged about
it you may still find yourself in hot water.  Stupid, I agree,
especially if they hired you as a security consultant.  But possible.

> Besides, having to stop and reinstall everything would make the lesson go 
> much slower. <g>

	Exactly.  [grin]
 
> Cool! I'm glad my idiotic screwups could help illustrate some points. (Hey, 
> that's why my totem is coyote... <g>)

	I was actually hoping that someone would make those very
mistakes.  I don't consider them idiotic at all.  Nobody's expected to
be letter-perfect when they're learning.  I know I'm not!  I have so
many "Raven screwed up horribly" stories.  I tend to share them when
someone feels bad about not having been perfect.  I once completely
downed a 300 machine network by making their firewall too restrictive.
No problem, I can fix it... hey, where did my telnet session go?  I'd
prohibited external telnet.  I'd forgotten that I was accessing the
firewall through external telnet.  Doh.  Talk about feeling silly.  I
had to call up someone local to the site and have them console in to fix
it.  So feel better.

Cheers,
Raven

Ben says "WAR IS PEACE FREEDOM IS SLAVERY BACKSPACE IS DELETE"