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

[Raven, corporate courtesan]

Heya --

Quoth jennyw (Sat, Apr 06, 2002 at 10:25:19PM -0800):
> They have an IT department and they use static addresses and have no
> firewall currently setup? Kind of scary!

	Yeah, that was one of the less likely gotchas in th scenario.
Possible, though.  I've run into it a few times. 
 
> Out of curiosity, why do you not like one-to-one NAT? For example, you 
> could do an el cheapo hot backup Web server solution by switching 
> addresses if the primary Web server is down (I've never done this, 
> but it doesn't sound very hard -- I have written scripts to monitor app. 
> servers and reboot them if certain functions weren't working).

	I think it's mostly because I generally feel that there's a
better way that it could be done.  (What that way is is situation
dependent, though.)  It feels like a kludge to me.  You can do the same
backup scenario by changing the IP address on your backup server
when the main one fails.  

	Probably this stems from seeing a lot of sysadmins who had o
idea how NAT really worked or how to troubleshoot it.  If you have good
sysadmins who understand your network, it's a stronger possibility.
 
> > 	Odds are you'll see Lots (tm) of http traffic, some POP and
> > IMAP, FTP, and a lot of less work-relevant things like kazaa, AIM,
> > Napster....  [grin]
> 
> Would we find anything scary?  Out of curiosity, how technical are the 
> users here? They have linux and some folks are ssh'ing in to do work.  
> It'd be nice to know the nature of the work they do over ssh (e.g. are 
> they accessing an accounting system? HTML files?).  If they have access to 
> something like, say, payroll, maybe management would think twice before 
> giving this access ...

	Good question.  The linux boxes are for their employees that
need to work from remote locations often.  They update sales and
inventory databases on their Linux boxes and check e-mail.  No payroll.

> I admit I'm used to the Windows world. We never had problems with NT
> Workstations losing their leases if the machines were on -- they renew
> automatically.

	With Linux, some dhcp clients do and some don't, I think.  I'm
not terribly experienced with this one, since the only *nix workstations
tended to be the admin boxes with static IPs.  Anyone with more
experience care to comment?

> I guess this is another reason to let them have static IPs.  Wow, their 
> own block.  Do they have redundant Internet connections? 

	Nope, they're just old.  [grin]
 
> Okay, I believe you, but I still don't get it :-( ... I keep thinking that
> 10.1.1.3 would be the broadcast address for the 10.1.1.0/30 subnet? I 
> don't mean to derail the discussion with subnet masking, but ...

	It would be.  That's right.  Do the diagrams in the reply to
Kai's mail in this thread make it any clearer?  Or did I screw up
somewhere and say that 10.1.1.3 was the next device in line after having
taken out a /30 already?  If that's the case, then severe apologies.  I
try to be correct especially when talking about subnetting, since it's
so confusing to most people.  10.1.1.3 can be a device in the DMZ if
everything in your subnet is allocated out of one /24, but if you've
already taken out a /30 then you've broken up that /24 into smaller
subnets, and can't allocate 10.1.1.3 to a machine.) 

> I would have thought that if you were using 10-space, you'd use
> something like 10.1.1.16/26 for the DMZ subnet, which would give you
> 10.1.1.17 (first firewall's internal interface)  up to 10.1.1.30, with
> 101.1.31 being the broadcast address.  Unless you wanted to save
> 10.1.1.0 for several /30 subnets, in which case you might use
> 10.1.2.0/26.  Of course, it's pretty rare that I've used subnets that
> aren't evenly divisible by 8, so it's absolutely possible I'm just
> very confused. I mean, beyond my normal confusedness.

	If you have any device that is going to do routing (i.e. a
router or a firewall), it's far, far easier to have different subnets
off its different interfaces.  That's one of the reasons that the /30s
are so favored for point to point links between devices that route.
Your allocation above is almost correct.  If you want to just carve off
10.1.1.16 to 10.1.1.31, that's 10.1.1.16/28, not /26.  

	The formula for the number of routable addresses in a netmask is
2 to the power of the number of bits in the host portion, minus two.  So
in this case that's 2 to the 4th (for a /28) , which is 16, minus two
(for the network addy and broadcast addy).  A /26 would have been six
bits in the host portion, so 2 to the 6th (64) minus two (62 routable
addresses).

	If you did the allocations as described above, you could use any
of the four /30's before 10.1.1.16 (10.1.1.0/30, 10.1.1.4/30,
10.1.1.8/30, or 10.1.1.12/30) for the point to point links and then
10.1.1.16/28 (10.1.1.16 to 10.1.1.31) for your DMZ, and still have a
10.1.1.32/27 (10.1.1.32 to 10.1.1.63), 10.1.1.64/26 (10.1.1.64 to
10.1.1.127), and 10.1.1.128/25 (10.1.1.128 to 10.1.1.255) left over to
do other things with.  (Basically, you'd have all the addresses in your
original /24 after 10.1.1.32 left.  But there's no way to represent 3/4
of a /24 as a subnet.  So you're stuck with smaller pieces, which can
get messy.)

> Of course, these are all non-routable IPs -- maybe to make things clearer, 
> we should s/10.1.1/a.b.c/g ... maybe my head would stop spinning ...

	Does the above make sense to you?  If not, please say so, and
I'll try to explain a different way.  Subnet masks are one of the most
confusing concepts in networking; mastering them is really something to
be proud of.
 
> Yeah. My confusion comes from having used Checkpoint ... things are so 
> different, since it figures out a lot of stuff for you. 

	Yeah.  I *hate* that, since I'm used to doing it by hand.  But
many other people love it for the convenience.  When we get to
configuring these rulesets and running nmap and tcpdump against them,
we'll actually see how it does that.

> You can deny ICMP incoming and allow it outgoing and it figures out
> when you initiated a ping -- control isn't as granular as with IP
> chains unless you want it. Doing things with IP chains definitely
> requires more knowledge of what's going on ...

	Yes.  That's why there are so many GUI front-ends to it, in an
attempt to make it easier and more like Checkpoint.

	You can do connection tracking for requests and replies, for
example.  Here's me pinging Google.

root at dahlia:~# tcpdump -n -i eth0
tcpdump: listening on eth0
00:41:38.599362 10.1.1.27 > 216.239.37.101: icmp: echo request (DF)
00:41:38.735314 216.239.37.101 > 10.1.1.27: icmp: echo reply
00:41:39.597204 10.1.1.27 > 216.239.37.101: icmp: echo request (DF)
00:41:39.725278 216.239.37.101 > 10.1.1.27: icmp: echo reply
00:41:40.597201 10.1.1.27 > 216.239.37.101: icmp: echo request (DF)
00:41:40.725257 216.239.37.101 > 10.1.1.27: icmp: echo reply
00:41:41.597200 10.1.1.27 > 216.239.37.101: icmp: echo request (DF)
00:41:41.725243 216.239.37.101 > 10.1.1.27: icmp: echo reply
00:41:42.597207 10.1.1.27 > 216.239.37.101: icmp: echo request (DF)
00:41:42.725213 216.239.37.101 > 10.1.1.27: icmp: echo reply

You can see the echo requests followed by an echo reply.  Some stateful
firewalls track outgoing requests and allow anything that seems to be a
reply to that request (like an echo reply from an IP you just
echo-requested from).
 
> > has the ACK bit set (i.e. is a reply to an outgoing connection) for TCP,
> > but there's no such handy catch for UDP.
> 
> Nifty. It's possible for someone to fake this, though, right?  I think you 
> said something about then when explaining stateful inspection with 
> iptables.

	Yep.  You have the ability to make a packet with just about any
headers and any content you want.  So if you can figure out what the
firewall will allow, you can make packets like that and they will get
through. 
 
> A bastion host would be another expense -- if they're okay with that, that 
> would be what I'd prefer. Mostly because it means that our firewall rules 
> would be simpler and because if we were to use DHCP on the workstations 
> with Dynamic DNS this would almost be necessary.

	That would be the solution I'd go for with the Linux boxes.
Give them private space IPs accessible from the bastion host (do port
forwarding of ssh on the second firewall to the bastion host).  Once
they have auth'd to the bastion host they can ssh to their own boxes.
And since they're now behind the second firewall along with the file
server, they can access it no problem, just like the Windows boxes. 
 
> If we wanted to log incoming IP addresses and the host they were going to, 
> we could install IP chains on the bastion host as well. So the network 
> would look like:
> 
> router -- fw1 -- dmz -- fw2 -- LAN (including bastion ssh host)
> 
> I don't think something like this would add much:
> 
> router -- fw1 -- dmz -- fw2 -- bastion ssh host
>                           \     |
>                            \-- LAN
> 
> The disadvantage of this would be that users would have to get used to 
> ssh'ing twice.  I guess this would be a discussion with the customer ...

	They'll do that.  (After all, it was what I had in mind.)
[grin]  So let's consolidate our network layout and firewall ruleset for
this topology, and then we'll move on to Read Raven's Mind Part II, er,
I mean, to iptables.
 
Cheers,
Raven

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