drop dhcp request from a particular mac address, after a dhcp relay

drop dhcp request from a particular mac address, after a dhcp relay

[Ming-Ching Tiew]

I would like to inhibit a dhcp request from a particular mac address, on the dhcp server.

If the client is directly LAN connected, I would suppose the following will work :-

iptables ....... -m mac --mac-source 

But to add a twist to the problem, the machine which must be blocked from obtaining a DHCP IP is connected to a DHCP relay, and therefore, the dhcp server is seeing only the mac adddress of the relay. Can this be accomplished with iptables ? 

Is there a match which works something like this :-

  iptables ..... -m bootp --mac-source 00:08:a1:ab:75:d1 -j DROP ?

Well, if 'iptables' can't serve the purpose, how about ebtables ?

Regards.




      

Re: drop dhcp request from a particular mac address, after a dhcp relay

[Robert Nichols]

On 03/10/2010 08:30 AM, Ming-Ching Tiew wrote:
>
> I would like to inhibit a dhcp request from a particular mac address, on the dhcp server.
>
> If the client is directly LAN connected, I would suppose the following will work :-
>
> iptables ....... -m mac --mac-source
>
> But to add a twist to the problem, the machine which must be blocked from obtaining a DHCP IP is connected to a DHCP relay, and therefore, the dhcp server is seeing only the mac adddress of the relay. Can this be accomplished with iptables ?
>
> Is there a match which works something like this :-
>
>    iptables ..... -m bootp --mac-source 00:08:a1:ab:75:d1 -j DROP ?
>
> Well, if 'iptables' can't serve the purpose, how about ebtables ?

Wouldn't it be a lot easier to adjust the DHCP server's configuration by
adding a "deny" statement in the pool's permit list?

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

Re: drop dhcp request from a particular mac address, after a dhcp relay

[Ming-Ching Tiew]

--- On Wed, 3/10/10, Robert Nichols <rnicholsNOSPAM@comcast.net> wrote:

 :-
> >
> >    iptables ..... -m bootp --mac-source
> 00:08:a1:ab:75:d1 -j DROP ?
> >
> > Well, if 'iptables' can't serve the purpose, how about
> ebtables ?
> 
> Wouldn't it be a lot easier to adjust the DHCP server's
> configuration by
> adding a "deny" statement in the pool's permit list?
> 

True but manually editing the configuration file will require the dhcp server to be restarted, whereas 'iptables' and/or 'ebtables' can be scripted at runtime.

Cheers. 




      

Re: drop dhcp request from a particular mac address, after a dhcp relay

[John Haxby]

On 12/03/10 02:27, Ming-Ching Tiew wrote:
> --- On Wed, 3/10/10, Robert Nichols<rnicholsNOSPAM@comcast.net>  wrote:
>
>    
>> Wouldn't it be a lot easier to adjust the DHCP server's
>> configuration by
>> adding a "deny" statement in the pool's permit list?
>>
>>      
> True but manually editing the configuration file will require the dhcp server to be restarted, whereas 'iptables' and/or 'ebtables' can be scripted at runtime.
>    

I'm curious.  Is that actually a problem?  In other words, what breaks 
when you restart the dhcp server?

jch

Re: drop dhcp request from a particular mac address, after a dhcp relay

[Mart Frauenlob]

On 12.03.2010 03:27, netfilter-owner@vger.kernel.org wrote:
> --- On Wed, 3/10/10, Robert Nichols <rnicholsNOSPAM@comcast.net> wrote:
> 
>  :-
>>>
>>>     iptables ..... -m bootp --mac-source
>> 00:08:a1:ab:75:d1 -j DROP ?
>>>
>>> Well, if 'iptables' can't serve the purpose, how about
>> ebtables ?
>>
>> Wouldn't it be a lot easier to adjust the DHCP server's
>> configuration by
>> adding a "deny" statement in the pool's permit list?
>>
> 
> True but manually editing the configuration file will require the dhcp server to be restarted, whereas 'iptables' and/or 'ebtables' can be scripted at runtime.
> 
> Cheers. 
> 

most likely the dhcp server should have a 'reload' parameter?
actually adding/inserting/deleting iptables rules does just the same (as
a service restart). the whole ruleset inside the kernel gets reloaded
for every single 'runtime' command you place. that is why there is
iptables-restore, which loads all rules at once.

Best regards


Mart

Re: drop dhcp request from a particular mac address, after a dhcp relay

[Robert Nichols]

On 03/13/2010 02:10 AM, Mart Frauenlob wrote:
> On 12.03.2010 03:27, netfilter-owner@vger.kernel.org wrote:
>> --- On Wed, 3/10/10, Robert Nichols<rnicholsNOSPAM@comcast.net>  wrote:
>>
>>   :-
>>>>
>>>>      iptables ..... -m bootp --mac-source
>>> 00:08:a1:ab:75:d1 -j DROP ?
>>>>
>>>> Well, if 'iptables' can't serve the purpose, how about
>>> ebtables ?
>>>
>>> Wouldn't it be a lot easier to adjust the DHCP server's
>>> configuration by
>>> adding a "deny" statement in the pool's permit list?
>>>
>>
>> True but manually editing the configuration file will require the dhcp server to be restarted, whereas 'iptables' and/or 'ebtables' can be scripted at runtime.
>>
>> Cheers.
>>
>
> most likely the dhcp server should have a 'reload' parameter?
> actually adding/inserting/deleting iptables rules does just the same (as
> a service restart). the whole ruleset inside the kernel gets reloaded
> for every single 'runtime' command you place. that is why there is
> iptables-restore, which loads all rules at once.

dhcpd does not have a "reload" action.  From the manpage for dhcpd:

     Whenever changes are made to the dhcpd.conf file, dhcpd must be
     restarted.  To restart dhcpd, send a SIGTERM (signal 15) to the
     process ID contained in /var/run/dhcpd.pid, and then re-invoke
     dhcpd.
     ...
     We realize that it would be nice if one could send a SIGHUP to the
     server and have it reload the database.  This is not technically
     impossible, but it would require a great deal of work, our resources
     are extremely limited, and they can be better spent elsewhere.

If you look at the "reload" action in the initscript, you'll see that
it actually performs a restart.  Since 'dhcpd' can be harmlessly
restarted there really should be no problem with doing that.

OTOH, if you're using 'dnsmasq' to perform the named and dhcpd services,
then restarting is a less attractive option.

As for iptables, if you're using a high-level firewall builder to
generate the rules, then yes, it will probably reload the entire rule
set if you make any change.  If you work at a lower level and use the
'iptables' command directly, then only the rule you add or change is
affected.  You can confirm that quite easily by running "iptables -vnL"
before and after the change and observing that the packet counts for
the other rules do not get reset.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

Re: drop dhcp request from a particular mac address, after a dhcp relay

[Mart Frauenlob]

On 13.03.2010 17:03, Robert Nichols wrote:
> On 03/13/2010 02:10 AM, Mart Frauenlob wrote:
>> On 12.03.2010 03:27, netfilter-owner@vger.kernel.org wrote:
>>> --- On Wed, 3/10/10, Robert Nichols<rnicholsNOSPAM@comcast.net>  wrote:
>>>
>>>   :-
>>>>>
>>>>>      iptables ..... -m bootp --mac-source
>>>> 00:08:a1:ab:75:d1 -j DROP ?
>>>>>
>>>>> Well, if 'iptables' can't serve the purpose, how about
>>>> ebtables ?
>>>>
>>>> Wouldn't it be a lot easier to adjust the DHCP server's
>>>> configuration by
>>>> adding a "deny" statement in the pool's permit list?
>>>>
>>>
>>> True but manually editing the configuration file will require the
>>> dhcp server to be restarted, whereas 'iptables' and/or 'ebtables' can
>>> be scripted at runtime.
>>>
>>> Cheers.
>>>
>>
>> most likely the dhcp server should have a 'reload' parameter?
>> actually adding/inserting/deleting iptables rules does just the same (as
>> a service restart). the whole ruleset inside the kernel gets reloaded
>> for every single 'runtime' command you place. that is why there is
>> iptables-restore, which loads all rules at once.
> 
> dhcpd does not have a "reload" action.  From the manpage for dhcpd:
> 
>     Whenever changes are made to the dhcpd.conf file, dhcpd must be
>     restarted.  To restart dhcpd, send a SIGTERM (signal 15) to the
>     process ID contained in /var/run/dhcpd.pid, and then re-invoke
>     dhcpd.
>     ...
>     We realize that it would be nice if one could send a SIGHUP to the
>     server and have it reload the database.  This is not technically
>     impossible, but it would require a great deal of work, our resources
>     are extremely limited, and they can be better spent elsewhere.
> 
> If you look at the "reload" action in the initscript, you'll see that
> it actually performs a restart.  Since 'dhcpd' can be harmlessly
> restarted there really should be no problem with doing that.
> 

well there's a reload command :p, they just hide it's actually a
restart, but as they say... no biggie.

> OTOH, if you're using 'dnsmasq' to perform the named and dhcpd services,
> then restarting is a less attractive option.
> 
> As for iptables, if you're using a high-level firewall builder to
> generate the rules, then yes, it will probably reload the entire rule
> set if you make any change.  If you work at a lower level and use the
> 'iptables' command directly, then only the rule you add or change is
> affected.  You can confirm that quite easily by running "iptables -vnL"
> before and after the change and observing that the packet counts for
> the other rules do not get reset.
> 

Speed considerations

One of the largest reasons for using the iptables-save and
iptables-restore commands is that they will speed up the loading and
saving of larger rule-sets considerably. The main problem with running a
shell script that contains iptables rules is that each invocation of
iptables within the script will first extract the whole rule-set from
the Netfilter kernel space, and after this, it will insert or append
rules, or do whatever change to the rule-set that is needed by this
specific command. Finally, it will insert the new rule-set from its own
memory into kernel space. Using a shell script, this is done for each
and every rule that we want to insert, and for each time we do this, it
takes more time to extract and insert the rule-set.

from:
http://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#SAVEANDRESTORE

While this packet processing is stalled!

Best regards

Mart

Re: drop dhcp request from a particular mac address, after a dhcp relay

[Sven-Haegar Koch]

On Sat, 13 Mar 2010, Robert Nichols wrote:

> As for iptables, if you're using a high-level firewall builder to
> generate the rules, then yes, it will probably reload the entire rule
> set if you make any change.  If you work at a lower level and use the
> 'iptables' command directly, then only the rule you add or change is
> affected.  You can confirm that quite easily by running "iptables -vnL"
> before and after the change and observing that the packet counts for
> the other rules do not get reset.

No, this is not correct.

The iptables command downloads the whole ruleset from the kernel, 
including current counter values, modifies the downloaded version, and 
then uploads the whole resulting ruleset (again, with counter 
values) into the kernel again.

This "download whole ruleset, modify in userspace, upload" cycle is why 
iptables-restore is so much faster than multiple calls to the iptables 
program - it only downloads once, applies all changes from the input, 
and then uploads back to the kernel once.

c'ya
sven-haegar

-- 
Three may keep a secret, if two of them are dead.
- Ben F.

Re: drop dhcp request from a particular mac address, after a dhcp relay

[Robert Nichols]

On 03/13/2010 01:29 PM, Sven-Haegar Koch wrote:
> On Sat, 13 Mar 2010, Robert Nichols wrote:
>
>> As for iptables, if you're using a high-level firewall builder to
>> generate the rules, then yes, it will probably reload the entire rule
>> set if you make any change.  If you work at a lower level and use the
>> 'iptables' command directly, then only the rule you add or change is
>> affected.  You can confirm that quite easily by running "iptables -vnL"
>> before and after the change and observing that the packet counts for
>> the other rules do not get reset.
>
> No, this is not correct.
>
> The iptables command downloads the whole ruleset from the kernel,
> including current counter values, modifies the downloaded version, and
> then uploads the whole resulting ruleset (again, with counter
> values) into the kernel again.
>
> This "download whole ruleset, modify in userspace, upload" cycle is why
> iptables-restore is so much faster than multiple calls to the iptables
> program - it only downloads once, applies all changes from the input,
> and then uploads back to the kernel once.

Indeed!  I looked at the iptables source, and that's exactly what happens.

Learn something new every day.  Thanks for the correction.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.