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

[Raven, corporate courtesan]

Heya --

Quoth jennyw (Tue, Apr 02, 2002 at 06:37:42PM -0800):
> My first question would be: What's your budget? ;-)

	[laughs]  It is important to know things like that.  Assume they
have a budget of a few thousand dollars, plus whatever they're paying
you.
 
> I suppose this might mean that there may be some services running on some 
> machines that depend on those IPs being the way they are ... I guess 
> before renumbering, I'd suggest figuring out what's going on on the 
> network.  Maybe by sniffing traffic destined/coming from those servers? 

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

> Unless management there is okay with just making the change and fixing 
> things later.  But if you did it the longer way you could probably do this 
> with minimal service interruptions.

	Yeah, and lack of downtime is always a good thing.  The more
stuff you can figure out and plan in advance, the less traumatic it's
likely to be when you do cut over.
 
> Renumbering customer-facing IP addresses probably wouldn't be necessary if
> you have your own CIDR block.

	It depends on what you're putting in the DMZ and what you're
not, partially.  I made it less evil than I could have, by putting all
the server IPs roughly close to each other.  

> You could use one-to-one NAT from the old addresses to the new
> addresses.

	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.

> Additionally, since clients are relying on DNS, changing the external
> numbers wouldn't be too bad, either -- DNS could resolve to the new
> addresses while the old addresses would still work for a while. I
> would make as few changes as possible at any given time. Completely
> redoing everything at once is asking for trouble. So a firewall with
> the simplest yet valuable ruleset first.

	Total good sense.  DNS cutovers can be done relatively
transparantly to the customers, and this sort of mentality is good
troubleshooting practice.
 
> I'd suggest initially setting up a firewall that allows all outgoing
> traffic from the internal network and logging everything so we figure out
> what's going out.

	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]

> Incoming traffic: 53 to DNS server, 25 to SMTP server, and 80 to Web
> server. If users need to check POP or IMAP, then we could do that,
> too, although I'd hope this wouldn't be needed.  We can add more rules
> after this first one works.  I suspect that some of the Windows folks
> are used to using AOL and IM programs.

	Yeah.  Usually I let their management decide what needs to be
allowed and what doesn't.  IME, workers are happier and more productive
if they are allowed to use things like AIM.  But some managers disagree.
 
> Eventually, though, it would be nice to give them access over https Web 
> mail and/or SSL IMAP/POP instead of cleartext.

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

> In any case, I'd want passwords changed as we do this, since some of
> them may have been sent in the clear before.  If they are identical to
> ssh passwords, we really have a problem, firewall or no ...

	They were.  Your client agrees to change all passwords, and to
make POP/FTP passwords different from ssh passwords.
 
> 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.

> 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.)
 
> The budget works its way in here. A single firewall computer with multiple 
> NICs or two firewalls?

	Your budget supports two firewalls.
 
> DHCP comes into play here.  I worked at a company that used static IPs and 
> ran out my first week or so of work.  And I'd never used Checkpoint 
> before then.  That was a lot of fun.  But I guess that's one way to learn! 
> ;-)

	Argh.  Nothing like trial by fire.
 
> > 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.
> 
> 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]

> I guess I would have used 192.168.x subnets for each subnet in between
> routers/firewalls. This is also useful in case you want to stick
> something else in those subnets (an IDS, for example).

	That's another possible solution.  It depends on whether you
need those links to be accessible to the rest of the world directly.  If
you want to use your routable space addresses to do it, just carve off
/30's (that's 255.255.255.252 netmask) for the point to point links, and
just use the remainder of your space for the large block of routableness
in the DMZ.
 
> 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.  

> 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.
 
> Sounds like a good reason to use iptables ...

	Yep.  Once we have a final ruleset for ipchains, we'll do
another example with iptables.
 
> How about ssh'ing to workstations? Those will need to be on a separate, 
> non IPmasq subnet, right?  Or can you write a rule that will 
> statically map them and except them from ipmasq? I should probably 
> read about this ... Nonetheless, I think it's a good idea to wait to do 
> any form of NAT until the outer firewall is setup and working.

	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?

Cheers,
Raven 
 
"Argh!  All these clocks are the same!"
  -- RavenBlack, on unexpected and new synchronicity