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

[jennyw]

On Wed, Apr 03, 2002 at 09:05:46PM -0500, Raven, corporate courtesan wrote:
> 	You could do that, but it would probably be easier to talk to
> their IT department and ask.  (You don't have to entirely trust their
> answers, but it at least gives you a starting point.)  

They have an IT department and they use static addresses and have no
firewall currently setup? Kind of scary!  I guess I just assumed that they
ended up with their current setup because they keep hiring consultants for
one-offs ... I guess we could consult with their IT folks, but I'm not 
sure I'd believe their answers.  In fact, the presence of an IT department 
might make me think that they only know enough to create more problems 
than expected ... ;-)

> 	You could, but as a long term solution this is somewhat
> inelegant.  It would work, mind you, but it complicates troubleshooting
> for other network problems.  I tend to avoid it, but I think that's a
> matter of taste.

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

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

> 	After you've explained, your client agrees to eventually migrate
> to non-cleartext protocols for internal use.

Yay!

> 	They were.  Your client agrees to change all passwords, and to
> make POP/FTP passwords different from ssh passwords.

I guess then we come up with a way to make sure this happens.  Of course, 
passwords could become a whole other discussion!  Maybe we could suggest 
one-time passwords for anything they access remotely.  Maybe we'd get 
lynched (or fired) if we did ...

> > 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.
> 
> 	The only problem is that if the Unix workstations lose their
> DHCP lease, and the user's not there to refresh it, they won't be able
> to ssh into their boxes remotely.  You're probably better off leaving
> them static'd and just documenting well.

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. Doesn't the ISC's DHCP client do the same?  Also, if we
reserved by MAC (which I would prefer not doing) this could be obviated.  
Also, what about Dynamic DNS?  I'm used to the Windows world where this
isn't such a hard thing but maybe there are issues in the Linux world (I'm
used to using Linux as a server and not a client, so I have virtually no
experience with DHCP cients under Linux).

I guess a small number of static IPs isn't bad, but if we were to scale to 
a company 10 times the size of our example, I'd really want to use DHCP 
for workstations.

> > 3. Easier to change ISPs (unless you own your own block of routable 
> > addresses).
> 
> 	Good catch -- assume your client does own their own IP block for
> this example.  (However, this is rare.)

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

> > > 	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?
> 
> 	Not really.  As far as the customer router is concerned,
> anything on your /24 is inbound on that Ethernet interface.  The links
> between the firewalls and routers are /30's -- one IP on each side.
> Cust FW1 one sees a /30 off eth0 and a /26 (or whatever) off eth1.
> Machines in the DMZ participate in that /26.  Cust FW2 has the last IP
> in that /26 on eth0, and a RFC 1918 private space /24 (for the winboxes
> or whatever) off eth1.
> 
> 	As long as all your machines speak CIDR, which almost every
> modern networking device does, you should be fine.
> 
> > I'm not entirely sure that's even possible.
> 
> 	Believe me, it is.  I make my living doing it.  [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 ...

I guess with the way I understand subnetting, if you had a subnet between
the router and the external interface of 10.1.1.0/30 it would include
10.1.1.0 (unknown), 10.1.1.1 (router's internal interface), 10.1.1.2
(first firewall's external interface), and 10.1.1.3 (broadcast).  So I
don't see how you could use 10.1.1.3 as the first address in the DMZ
subnet (int.  interface of the first firewall).  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.

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

> > 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.
> 
> 	Yep.  You should allow ICMP message type 3 packets incoming,
> since they're your error messages, and ensure things like Path MTU
> discovery won't break.  Also, ICMP message type 0 incoming (echo reply)
> is a good idea if you want your users to be able to ping other machines.  

Yeah. My confusion comes from having used Checkpoint ... things are so 
different, since it figures out a lot of stuff for you.  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 ...

> > 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.
> 
> 	Yep.  Other things like proxy servers, common filesharing
> applications, all live on high ports.  You can get around this sort of
> thing by making rules that allow incoming traffic on high ports if it
> 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.

> 	Aha!  This is what I was hoping someone would catch.  The users
> that need to ssh to their workstations will need to ssh to something
> that is routable.  So if those boxes go behind the second firewall too,
> they'll either have to have routable IPs, have a port forwarded through
> the firewall that they can ssh to (since the external interface of
> firewall 2 will be routable), or have some sort of a bastion host set up
> that they can ssh to, and then ssh from that to their workstation.
> 
> 	Which of those options do you think would be best?

If they don't change IPs often, the easiest thing to start off with would
be to leave them with routable IPs, then migrate them to the next step.  
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.

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

Jen