We have a DHCP server running on a central server behind our Shorewall
firewall (shorewall-perl-4.0.6). We have some 200 hosts all on the
same subnet and all behind that firewall.
We use
1. (mostly) fixed IP addresses assigned to Mac addresses so that every
registrered machine always gets the same IP address if he sets his PC
to ''automatically obtain an IP address'' (DHCP)
2. a number of PCs where the TCP/IP addresses are set manually in the PC
(not using DHCP) and recorded as known of/allowed.
3. a small pool of dynamically leased addresses specified in our DHCP server
(for visitors).
But sometimes some user does not set his PC to ''automatically obtain
an IP address'' (DHCP) but puts in an IP address manually in his TCP/IP
configuration ... and if that IP address was already registrered
for someone else''s MACaddress, the DHCP server will not hand out that
IP when it finds that IP address is in use, leaving the rightfull
''owner'' of that IP address without network connection ...
How can we make this impossible?
I took a look at www.shorewall.net/MAC_Validation.html
but have questions:
- /etc/shorewall/maclist: has no column ''DISPOSITION'' in
Example 1,
does this mean, the MACLIST_DISPOSITION=REJECT from shorewall.conf is
applied to all lines (as if all lines contained a first Column
''REJECT'')
- The MAC-addresses/IP-addresses combinations registrered in our
DHCP server (1.) and the ones manually set (2.) must all be in
/etc/shorewall/maclist ?
- What about the dynamically leases addresses: here the MAC address
can vary, only the pool of IP adresses is fixed.
If I understand well, putting in the MAC column a dash (-) and a
commad-delimited set of IP-addresses in the IPADRESSES column, this
would be sufficient?
- what''s that remark about "Your kernel must include MAC match
support
(CONFIG_IP_NF_MATCH_MAC - module name ipt_mac.o)." How can I find out
if this is included on a SUSE 10.2 or SUSE 10.3 ?
- How to find out if "If your kernel and iptables have iprange match
support then IP address ranges are also allowed" for SUSE 10.2 and
SUSE 10.3 ?
------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
Pieter Donche wrote:> We have a DHCP server running on a central server behind our Shorewall > firewall (shorewall-perl-4.0.6). We have some 200 hosts all on the > same subnet and all behind that firewall. > We use > 1. (mostly) fixed IP addresses assigned to Mac addresses so that every > registrered machine always gets the same IP address if he sets his PC > to ''automatically obtain an IP address'' (DHCP) > 2. a number of PCs where the TCP/IP addresses are set manually in the PC > (not using DHCP) and recorded as known of/allowed. > 3. a small pool of dynamically leased addresses specified in our DHCP server > (for visitors). > > But sometimes some user does not set his PC to ''automatically obtain > an IP address'' (DHCP) but puts in an IP address manually in his TCP/IP > configuration ... and if that IP address was already registrered > for someone else''s MACaddress, the DHCP server will not hand out that > IP when it finds that IP address is in use, leaving the rightfull > ''owner'' of that IP address without network connection ... > > How can we make this impossible? > > I took a look at www.shorewall.net/MAC_Validation.html > but have questions: > > - /etc/shorewall/maclist: has no column ''DISPOSITION'' in Example 1, > does this mean, the MACLIST_DISPOSITION=REJECT from shorewall.conf is > applied to all lines (as if all lines contained a first Column ''REJECT'')I''ve removed the last two sections of that article to avoid confusion. The shorewall-maclist (5) manpage is much clearer anyway.> > - The MAC-addresses/IP-addresses combinations registrered in our > DHCP server (1.) and the ones manually set (2.) must all be in > /etc/shorewall/maclist ?Depends on how you set it up. If you set MACLIST_DISPOSITION=ACCEPT then you might only add entries in /etc/shorewall/maclist for those that are manually set -- specify both MAC and IP ADDRESS.> - What about the dynamically leases addresses: here the MAC address > can vary, only the pool of IP adresses is fixed. > If I understand well, putting in the MAC column a dash (-) and a > commad-delimited set of IP-addresses in the IPADRESSES column, this > would be sufficient?Or only the MAC addresses.> > - what''s that remark about "Your kernel must include MAC match support > (CONFIG_IP_NF_MATCH_MAC - module name ipt_mac.o)." How can I find out > if this is included on a SUSE 10.2 or SUSE 10.3 ? > > - How to find out if "If your kernel and iptables have iprange match > support then IP address ranges are also allowed" for SUSE 10.2 and > SUSE 10.3 ?See Shorewall FAQ 42. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get
Tom Eastep wrote:> Pieter Donche wrote: >> We have a DHCP server running on a central server behind our Shorewall >> firewall (shorewall-perl-4.0.6). We have some 200 hosts all on the >> same subnet and all behind that firewall. >> We use >> 1. (mostly) fixed IP addresses assigned to Mac addresses so that every >> registrered machine always gets the same IP address if he sets his PC >> to ''automatically obtain an IP address'' (DHCP) >> 2. a number of PCs where the TCP/IP addresses are set manually in the PC >> (not using DHCP) and recorded as known of/allowed. >> 3. a small pool of dynamically leased addresses specified in our DHCP server >> (for visitors). >> >> But sometimes some user does not set his PC to ''automatically obtain >> an IP address'' (DHCP) but puts in an IP address manually in his TCP/IP >> configuration ... and if that IP address was already registrered >> for someone else''s MACaddress, the DHCP server will not hand out that >> IP when it finds that IP address is in use, leaving the rightfull >> ''owner'' of that IP address without network connection ... >> >> How can we make this impossible? >> >> I took a look at www.shorewall.net/MAC_Validation.html >> but have questions: >> >> - /etc/shorewall/maclist: has no column ''DISPOSITION'' in Example 1, >> does this mean, the MACLIST_DISPOSITION=REJECT from shorewall.conf is >> applied to all lines (as if all lines contained a first Column ''REJECT'') > > I''ve removed the last two sections of that article to avoid confusion. > The shorewall-maclist (5) manpage is much clearer anyway.I''ve now re-added an updated example that will hopefully be clearer. Each entry in the maclist file is an ACCEPT entry. So matching entries are accepted and all others are REJECTed. Hope that helps, -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get
> > We have a DHCP server running on a central server behind our Shorewall > > firewall (shorewall-perl-4.0.6). We have some 200 hosts all on the > > same subnet and all behind that firewall. > > We use > > 1. (mostly) fixed IP addresses assigned to Mac addresses so that every > > registrered machine always gets the same IP address if he sets his PC > > to ''automatically obtain an IP address'' (DHCP) > > 2. a number of PCs where the TCP/IP addresses are set manually in the PC > > (not using DHCP) and recorded as known of/allowed. > > 3. a small pool of dynamically leased addresses specified in our DHCP server > > (for visitors). > > > > But sometimes some user does not set his PC to ''automatically obtain > > an IP address'' (DHCP) but puts in an IP address manually in his TCP/IP > > configuration ... and if that IP address was already registrered > > for someone else''s MACaddress, the DHCP server will not hand out that > > IP when it finds that IP address is in use, leaving the rightfull > > ''owner'' of that IP address without network connection ... > > > > How can we make this impossible? > > > > I took a look at www.shorewall.net/MAC_Validation.html > > but have questions: > > > > - The MAC-addresses/IP-addresses combinations registrered in our > > DHCP server (1.) and the ones manually set (2.) must all be in > > /etc/shorewall/maclist ? > > Depends on how you set it up. If you set MACLIST_DISPOSITION=ACCEPT then > you might only add entries in /etc/shorewall/maclist for those that are > manually set -- specify both MAC and IP ADDRESS.But if I would use MACLIST_DISPOSITION=ACCEPT and only record entries for those that are manually set (2.), wouldn''t this leave the possibility open that a user manually sets in his PC an IPaddress which is already reserved in our DHCP server (case 1.) for someone elses PC, causing the trouble that the DHCP server will not hand out that IP to the rightfull ''owner'' when that IP is in use ... (as I mentionned in my initial mail) So I believe that my only option is to specify all the DHCP-fixed assigned MAC/IP addresses in maclist. Or do I misunderstand ? (then what am i missing here?)> > > - What about the dynamically leases addresses: here the MAC address > > can vary, only the pool of IP adresses is fixed. > > If I understand well, putting in the MAC column a dash (-) and a > > commad-delimited set of IP-addresses in the IPADRESSES column, this > > would be sufficient? > > Or only the MAC addresses.But I want to avoid that a visitor for only a few days, would need to ask me to record his Mac address. So I believe that my only option then is to use a dash in Mac column and a comma-delimited set of IPaddresses in the IPADDRESSES column. Is that right?> > > - what''s that remark about "Your kernel must include MAC match support > > (CONFIG_IP_NF_MATCH_MAC - module name ipt_mac.o)." How can I find out > > if this is included on a SUSE 10.2 or SUSE 10.3 ? > > - How to find out if "If your kernel and iptables have iprange match > > support then IP address ranges are also allowed" for SUSE 10.2 and > > SUSE 10.3 ? > See Shorewall FAQ 42.# shorewall show capabilities reports the following (see below): So I have iprange match support, no ipset support, but what about ''MAC match support''? Do I have it or not? - I don''t see something in the ''Available'' or ''Not Available'' lines, or does it correspond to ''Physdev match'' or what ? Shorewall has detected the following iptables/netfilter capabilities: NAT: Available Packet Mangling: Available Multi-port Match: Available Extended Multi-port Match: Available Connection Tracking Match: Available Packet Type Match: Available Policy Match: Available Physdev Match: Available Physdev-is-bridged Support: Available Packet length Match: Available IP range Match: Available Recent Match: Available Owner Match: Available Ipset Match: Not available CONNMARK Target: Available Extended CONNMARK Target: Available Connmark Match: Available Extended Connmark Match: Available Raw Table: Available IPP2P Match: Not available CLASSIFY Target: Available Extended REJECT: Available Repeat match: Available MARK Target: Available Extended MARK Target: Available Mangle FORWARD Chain: Available Comments: Available Address Type Match: Available TCPMSS Match: Available Hashlimit Match: Available NFQUEUE Target: Available ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get
Pieter Donche wrote:> > Depends on how you set it up. If you set MACLIST_DISPOSITION=ACCEPT then >> you might only add entries in /etc/shorewall/maclist for those that are >> manually set -- specify both MAC and IP ADDRESS. > >But if I would use MACLIST_DISPOSITION=ACCEPT and only record entries for >those that are manually set (2.), wouldn''t this leave the possibility open >that a user manually sets in his PC an IPaddress which is already >reserved in our DHCP server (case 1.) for someone elses PC, causing the >trouble that the DHCP server will not hand out that IP to the rightfull >''owner'' when that IP is in use ... (as I mentionned in my initial mail)Personally I would suggest that rather than trying to do this in the firewall, you set up some form of monitoring to compare ARP tables against a predefined list. This can be done (in some cases) by querying switches, or by checking the ARP table on some host in the network (which can be your firewall - or any other host that the device would need to communicate with before getting internet access). I think it might be easier doing it that way - so you can write your own scripts to work as you want, rather than trying to force a general purpose tool to do what you want. It shouldn''t be hard to query the ARP table, compare each entry to a predefined list (generated from the same source data that you generate your DHCP config from), and flag up any bad entries. Once you''ve flagged up a rogue entry, then you still have to do something - you could block it by blacklisting the MAC address in Shorewall, or send an email to an administrator, or both, or something else. Whatever you do, human intervention is going to be required to track down and "fix" the problem - typically by "educating" the user on the error of his ways. Until you have fixed the problem, then the other user who''s IP address has been hijacked will still not be able to work on the network - unless you run a fully managed network and are able to isolate the rogue device at it''s local network switch (again something you won''t achieve from a Shorewall config).>But I want to avoid that a visitor for only a few days, would need to ask >me to record his Mac address.Have a separate pool for visitors, and exclude those addresses from your checking scripts. At work we had a related issue. Someone setup a new device for the outside network (we offer hosting services amongst other things) and chose an address that was already in use*. It took some time before I was able to work out what had happened and correct the situation, and meanwhile a customer was "a tad upset" that his IP phone system was down. I''ve since added monitoring in our Nagios system to check the ARP of every IP address (including all the empty addresses) on our outside network and raise alerts whenever a MAC address changes/appears/disappears. It takes a little effort to keep everything up to date, but a lot less than trying to track down problems after they''ve happened ! It also means that we now have a complete inventory of devices on the network which we didn''t have before. * He pinged it first, but of course, many devices these days don''t respond to pings in some futile attempt to avoid being "seen" and attacked. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get
Pieter Donche wrote:> Tom Eastep wrote:>> >> Depends on how you set it up. If you set MACLIST_DISPOSITION=ACCEPT then >> you might only add entries in /etc/shorewall/maclist for those that are >> manually set -- specify both MAC and IP ADDRESS. > > But if I would use MACLIST_DISPOSITION=ACCEPT and only record entries for > those that are manually set (2.), wouldn''t this leave the possibility open > that a user manually sets in his PC an IPaddress which is already > reserved in our DHCP server (case 1.) for someone elses PC, causing the > trouble that the DHCP server will not hand out that IP to the rightfull > ''owner'' when that IP is in use ... (as I mentionned in my initial mail) > > So I believe that my only option is to specify all the DHCP-fixed > assigned MAC/IP addresses in maclist. > > Or do I misunderstand ? (then what am i missing here?)As far as I''m concerned, your fixed assignments from your DHCP server are ''manually set''. Question of terminology.> >> >> > - What about the dynamically leases addresses: here the MAC address >> > can vary, only the pool of IP adresses is fixed. >> > If I understand well, putting in the MAC column a dash (-) and a >> > commad-delimited set of IP-addresses in the IPADRESSES column, this >> > would be sufficient? >> >> Or only the MAC addresses. > > But I want to avoid that a visitor for only a few days, would need to ask > me to record his Mac address. So I believe that my only option then is > to use a dash in Mac column and a comma-delimited set of IPaddresses in the > IPADDRESSES column. > > Is that right?No. In fact, you can set MACLIST_DISPOSITION=REJECT Hopefully, you have segregated the three types of assignment into separate IP address ranges. Let''s call them R1, R2, and R3 for Fixed-DHCP-assigned, Manually-set and Dynamically-DHCP-assigned. Your maclist file then has three groups of records: #R1 - DHCP-assigned addresses ACCEPT dhcp-mac-1 dhcp-assigned-addr-1 ACCEPT dhcp-mac-2 dhcp-assigned-addr-2 ... REJECT - R1 R2 - Manual assignments ACCEPT manual-mac-1 manual-addr-1 ACCEPT manual-mac-2 manual-addr-2 ... REJECT - R2 R3 - Visitors ACCEPT - R3 Note that every new connection entering from the ''maclist'' interface will have to march through this list. If the list is long, you might be better off to create 3 Actions. A0, A1, A2 A0: A1 R1 A2 R2 ACCEPT R3 REJECT - A1: ACCEPT dhcp-mac-1 dhcp-assigned-addr-1 ACCEPT dhcp-mac-2 dhcp-assigned-addr-2 A2: ACCEPT dhcp-mac-1 dhcp-assigned-addr-1 ACCEPT dhcp-mac-2 dhcp-assigned-addr-2 At the top of the NEW section in your rules file: A0 z:ethX ALL Where z is the zone associated with ethX. Note that in this approach, all MAC addresses must be expressed in Shorewall format. This approach avoids matching R2 traffic against all R1 rules and avoids matching R3 traffic against all R1 and R2 rules. If the lists are long though, it still means that the average new connection will need to traverse 1/2 of the rules associated with the SOURCE IP''s range. As Simon has pointed out, all of this doesn''t stop users from doing something dastardly and disrupting your operation; they just won''t get any useful work done at the same time. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get