Hi all,
I''m new to this list, so please excuse my ignorance of any customs here
;-)
(My system is a pc with mandrake 9.0, shorewall 1.3.7c and 2 interfaces)
I have a question about the order of the norfc1918 rules and the dhcp rules
on an interface...
On the website I found a reference to this problem with version 1.3.7a in
that when the norfc1918 rules were applied before the dhcp passthrough this
was a problem:
(quote 1.3.7a errata)
If "norfc1918" and "dhcp" are both specified as options
on a given
interface then RFC 1918 checking is occurring before DHCP checking. This
means that if a DHCP client broadcasts using an RFC 1918 source address,
then the firewall will reject the broadcast (usually logging it). This
has two problems:
1. If the firewall is running a DHCP server, the client won''t be
able
to obtain an IP address lease from that server.
2. With this order of checking, the "dhcp" option cannot be used
as a
noise-reduction measure where there are both dynamic and static
clients on a LAN segment.
I''m on a cable modem and I have 2 interfaces (actually very much like
the
example setup for a simple 2 interface firewall). On the internet side I get
a dynamic internet routable address and on the other side I run a dhcp
server for the back-end network (192.168/16 type). My interfaces file looks
like this:
#ZONE INTERFACE BROADCAST OPTIONS
net eth0 detect norfc1918,dhcp
masq eth1 detect dhcp
I noticed that dhcp packets arrive on eth0 not just from the ISP range, but
also from a 10.x.x.x range. This has not yet been a problem, but I can
imagine that some nasty person could give me a bad ip-address and DoS me
that way. So in this example I would like to have norfc1918 filtering before
dhcp passthrough on eth0. On eth1 the norfc filter should not ever be
applied.
The questions I have are:
- Am I correct that this is a problem?
- How can I tell shorewall (1.3.7c) to turn these rules around? (I could
locate the script and change it, but I guess a configuration option would be
more clear/neat)
Cheers and TIA
Simon
--On Friday, November 08, 2002 10:15 AM +0100 Simon Oosthoek <simon@margo.student.utwente.nl> wrote:> I noticed that dhcp packets arrive on eth0 not just from the ISP range, > but also from a 10.x.x.x range. This has not yet been a problem, but I can > imagine that some nasty person could give me a bad ip-address and DoS me > that way. So in this example I would like to have norfc1918 filtering > before dhcp passthrough on eth0. On eth1 the norfc filter should not ever > be applied.I don''t understand "could give me a bad ip-address and DoS me". Are you concerned that some host using a 10.x.x.x address will run a DHCP server and issue you a bogus IP address? If so, a host with ANY IP address could do that. I guess I don''t understand what your concern is. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
On Fri, Nov 08, 2002 at 06:38:10AM -0800, Tom Eastep wrote:> > > --On Friday, November 08, 2002 10:15 AM +0100 Simon Oosthoek > <simon@margo.student.utwente.nl> wrote: > > >I noticed that dhcp packets arrive on eth0 not just from the ISP range, > >but also from a 10.x.x.x range. This has not yet been a problem, but I can > >imagine that some nasty person could give me a bad ip-address and DoS me > >that way. So in this example I would like to have norfc1918 filtering > >before dhcp passthrough on eth0. On eth1 the norfc filter should not ever > >be applied. > > I don''t understand "could give me a bad ip-address and DoS me". Are you > concerned that some host using a 10.x.x.x address will run a DHCP server > and issue you a bogus IP address? If so, a host with ANY IP address could > do that. > > I guess I don''t understand what your concern is.Maybe I don''t understand DHCP that well, but if I don''t know what domain I belong to and rely on the DHCP server to give me an address, how can I tell which is right or wrong, the ISP one or the 10.x.x.x one? Anyway, apart from the technical reason in DHCP, my concern is also that if I specify to reject all rfc1918 address ranges on an interface I expect it to be done before anything tries to make sense out of the arriving packets. To me that is sound firewall policy ;-) I turned it around in the firewall script of shorewall to please myself, but I''d love a good explanation why it breaks things as stated in the errata for shorewall 1.3.7a... Cheers Simon PS I think shorewall is really a Good Thing(tm), however when you don''t write your own iptables rules it takes a while to understand the reasoning behind everything...
--On Saturday, November 09, 2002 08:58:13 PM +0100 Simon Oosthoek <simon@margo.student.utwente.nl> wrote:> > I turned it around in the firewall script of shorewall to please myself, > but I''d love a good explanation why it breaks things as stated in the > errata for shorewall 1.3.7a... >The problem is that as available IPV4 addresses become more scarce, ISP are beginning to use RFC1918 addresses for their own internal systems, INCLUDING DHCP SERVERS! So with the order of the rules reversed as they used to be, if your ISP was using this technique then with Shorewall started you couldn''t get an IP address from your ISP''s server and you couldn''t renew your current lease from that server. Given that a number of people wrote me to complain about that problem, I reversed the order of DHCP and RFC1918 checking so that their firewall''s were able to function. As to your concern, the fact that there are both RFC 1918 and non-RFC 1918 IP addresses on your external subnet MAY mean that your ISP is also using RFC 1918 addresses internally but not for DHCP servers. And even if the RFC 1918 IP address aren''t part of your ISP''s infrastructure, DHCP uses the limited broadcast address (255.255.255.255) so a bogus DHCP server with a legitimate address can do just as much harm as one using an RFC 1918 address. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://shorewall.sf.net ICQ: #60745924 \ teastep@shorewall.net
On Sat, Nov 09, 2002 at 05:24:48PM -0800, Tom Eastep wrote:> > > --On Saturday, November 09, 2002 08:58:13 PM +0100 Simon Oosthoek > <simon@margo.student.utwente.nl> wrote: > > > > > >I turned it around in the firewall script of shorewall to please myself, > >but I''d love a good explanation why it breaks things as stated in the > >errata for shorewall 1.3.7a... > > > > The problem is that as available IPV4 addresses become more scarce, ISP are > beginning to use RFC1918 addresses for their own internal systems, > INCLUDING DHCP SERVERS! So with the order of the rules reversed as they > used to be, if your ISP was using this technique then with Shorewall > started you couldn''t get an IP address from your ISP''s server and you > couldn''t renew your current lease from that server. Given that a number of > people wrote me to complain about that problem, I reversed the order of > DHCP and RFC1918 checking so that their firewall''s were able to function. > > As to your concern, the fact that there are both RFC 1918 and non-RFC 1918 > IP addresses on your external subnet MAY mean that your ISP is also using > RFC 1918 addresses internally but not for DHCP servers. And even if the RFC > 1918 IP address aren''t part of your ISP''s infrastructure, DHCP uses the > limited broadcast address (255.255.255.255) so a bogus DHCP server with a > legitimate address can do just as much harm as one using an RFC 1918 > address.It appears you''re right, my ISP seems to use both routable and non-routable addresses on their network. I get DHCP packets from the "official" DHCP server and from this 10.x.x.x address. After some checking with ethereal I get the feeling the 10.x.x.x host is proxy-arping for other parts of the network, but why it is sourcing DHCP offers, I have no idea... Anyway, I changed the rules back to allow DHCP from any host (since you showed how it doesn''t matter anyway ;-) but I modified the rfc1918 config in /etc/shorewall to just DROP any packets from 10.x.x.x, instead of logdropping thousands of packets a day :-( Cheers and thanks for the explanation Simon Oh BTW, another strange thing with my ISP, my "hostname" resolves to a different address (different subnet) than my current IP address, which does reverse resolve into the right hostname... Is that common too?
--On Monday, November 11, 2002 09:03:09 AM +0100 Simon Oosthoek <simon@margo.student.utwente.nl> wrote:> On Sat, Nov 09, 2002 at 05:24:48PM -0800, Tom Eastep wrote: > > Oh BTW, another strange thing with my ISP, my "hostname" resolves to a > different address (different subnet) than my current IP address, which > does reverse resolve into the right hostname... Is that common too?Reverse resolution problems are very common but ISPs usually can get forward resolution right. You may want to follow up with your ISP on that one. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://shorewall.sf.net ICQ: #60745924 \ teastep@shorewall.net