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

[Kai MacTane]

At 4/1/02 06:25 PM , Raven, corporate courtesan wrote:
>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.

I think most people do.

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

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

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

Fair enough.

>         Feel free to advise your client to renumber, but you may want to
>see what sort of a business they're running first.
>[snip]
>         As it happens, this particular client is a widget maker...
>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.

Nah, I'm not bothered by it. I was mostly jut wondering. 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.)

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

Good. I'm always pleased by signs that clients aren't morons.

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

Thus confirming my initial point. Okay, they expect this to stay in service 
until it can't any more. Not that bad an expectation, especially since 
*they're willing to be up-front about it*. That's fine.

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

Groovy.

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

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

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

Ummm... Had I been thinking properly, I'm sure I would have meant that.

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

I seem to have had a double dumbass attack here. Yes, I'm thinking .1 for 
the outer interface, and I completely forgot that the inner one exists and 
needs an IP address.

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

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. So I'd set it up as 10.1.1.1 on the outer interface, 
and 10.1.1.2 on the inner one.

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

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

Thanks!

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

I think I actually did that in the ruleset later on.

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

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

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

Then it's all set; just uncomment those rules.

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

Oops! Yes, indeed.

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

I see it's expanded some from the specific meaning given at:
http://www.tuxedo.org/~esr/jargon/html/entry/martian.html

(Though I do like ESR's phrasing of "it will come back labeled with a 
source address that is clearly not of this earth.")

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

You are so right. I personally have little beef with ICMP packets. Some of 
them you *definitely* want to accept, like TTL expired, host unreachable, 
and so forth. It would be good to be able to ping and traceroute to stuff 
on the rest of the Net.

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

right after the Martian-catching rules. (So, if someone pings my network 
claiming to be from my network, I'll log-and-drop their packets -- and how 
would the echo_reply get to them, anyway? But if it's a "real" ping, I'll 
pong.)

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

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

That's part of why I took option number one.

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

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. 
It's not going to look like a hostile attack coming from somewhere else. 
 From the other things they've said, I must admit I kind of... um... 
assumed" <g> that they wouldn't even notice me running an internal nmap 
scan. If they go "Hey, what's up with the network?", I can just tell them 
"I'm running some security scans on the servers to make sure they're locked 
down tight."

Nonetheless, I suspect that in the future, I should at least warn them 
before doing stuff like that. Good point.

>You don't find anything untoward.  Since this network has been on the 
>Internet unfirewalled, this is an amazing miracle.  [grin]

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

> > Since my current setup probably doesn't provide even basic 
> functionality, I
> > doubt it's the best.
>
>         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.

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

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

I'll get back to you on that in a couple of days, when I have a bit more time.

                                                 --Kai MacTane
----------------------------------------------------------------------
"Before you slip into unconsciousness,
  I'd like to have another kiss,
  Another flashing chance at bliss..."
                                                 --The Doors,
                                                  "The Crystal Ship"