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

[Raven, corporate courtesan]

Heya --

Quoth Hamster (Sat, Apr 13, 2002 at 01:22:27AM +0200):
> But I have found that the choice of dhcp client can make a difference.
> The two I know of are dhcpcd (client daemon) and one called pump. I am
> a loyal pump fan, as a lot of dhcp probs I've had have been solved by
> swapping to pump. Including problems about not having leases renewed.

	Yeah, with my (very limited) experience of DHCP on Linux, I saw
some similar behaviour.
 
> > 00:41:38.599362 10.1.1.27 > 216.239.37.101: icmp: echo request (DF)
> 
> Does the DF here mean dont fragment? Or maybe dont feed, or dirty feet ;-)

	Yep, Don't Fragment.  Go you.  (Don't Fragment is a flag that
can be set to request that this IP packet not be broken up into smaller
packets in transit.  Normally if a packet is bigger than the MTU
(Maximum Transmission Unit) of a link, it's fragmented into smaller
packets that can fit over that link.  So if you try to send a 4464 byte
packet over a link with an MTU of 1500, you'll get two 1500 byte packets
and a 1464 byte packet sent instead (ignoring padding and its effects).
But if the Don't Fragment flag is set and the packet is bigger than the
max size allowed over a link, the packet is dropped and an ICMP error is
generated and sent back to the source of the packet.  It's something
like "Error: Fragmentation Required But Don't Fragment Is Set".  

	Path MTU discovery, which we've mentioned a couple of times in
our firewall discussion, depends on you recieving this error.  So this
is another good sort of ICMP to allow through your firewall.  (It's an
ICMP message type 3, which are the error messages in general.  So if
you're allowing all ICMP error messages, you're okay for Path MTU.)

	You can read more about the Don't Fragment bit and Patm MTU
discovery at http://www.worldgate.com/~marcs/mtu/ if you're interested.

> > > A bastion host would be another expense
> 
> A what host? Even a url to explain this one would be helpful :)
 
	A bastion host is a machine that selectively allows less trusted
users access to a more secure network.  For example, I am turning up a
new network that's not totally connected to the Internet yet.  But I
need to be able to download things to install them onto the new network.
So I set up a computer that's connected to both the Internet and my new
network.  The only service that it's running is ssh.  So I can ssh into
the bastion host, and from there ssh to the machines on my new network,
make config changes, upgrade operating systems, etc.  But the machines
on the new network cannot access the outside world, and the machines on
the Internet cannot access my new network.  

	For the purposes of our last example, if we wanted the Linux
users to be able to ssh into their workstations on the protected
network, we could set up a bastion host that they could ssh into, one
with either a routable IP of its own located in the DMZ, or one behind
the second firewall with port 22 on the second firewall forwarded to it
(this is the option I'd favor, as it avoids weird routing foo).  Then
the Linux users could ssh to the bastion host, and from the bastion host
to their workstations.  That way they have connectivity, and we only had
to make one small hole in the firewall.

	The basic idea behind a bastion host is to minimize the things
allowed through your network that aren't coming from trusted computers,
know where they're coming through, and watch that system.  More
information is available at:

http://www.sans.org/newlook/resources/IDFAQ/bastion.htm

Cheers,
Raven

"It's all part of my evil plot! Did I mention I was grown in a lab for
 specifically this purpose?"
  -- Anne, on perfection