[bdNOG] DHCP Lease and Network Problem Help (Mohammad Shahjahan)

Mon Dec 7 14:36:50 BDT 2015

On 07/12/2015 06:00, nog-request at bdnog.org wrote:
> For an Example: Suppose your gateway IP is 192.168.1.1, then you can 
> implement Standard ACL on the switchport (from where your users are 
> connected to)
>
> Switch(config)#access-list 1 deny host 192.168.1.1
> Switch(config)#access-list 1 permit any
>
> Switch(config)#interface fastEthernet 0/1
> Switch(config-if)#ip access-group 1 in
>
I'm not sure that's going to help, unless it filters ARP responses as 
well as IP datagrams. That is: it will stop the person with address 
192.168.1.1 from using the Internet, but it probably won't stop the 
breakage of the other users.

Consider a packet which is going out from PC 192.168.1.100 to the 
Internet, say IP address 8.8.8.8.

Neither of those packets has 192.168.1.1 as a source or destination 
address, so it won't be affected by the filter. However, the PC knows 
that its default gateway is 192.168.1.1, so will send an ARP request for 
192.168.1.1 to learn the MAC address.

Your router will respond, but so will the hijacker who has manually 
configured 192.168.1.1 as their IP address. Whichever response arrives 
first will be the one which is used, so it's just a race.

If the hijacker's response arrives first, the PC will encapsulate their 
packet with the hijacker's MAC address and deliver it there instead of 
to the Internet. If the hijacker has IP forwarding enabled they may 
re-send it to the router (note that they will be able to sniff all 
outbound traffic!) But most likely the packet will be dropped on the 
floor and connectivity will be broken.

So, to fix this problem properly you would have to do filtering of ARP 
responses; enforce that ARP responses for 192.168.1.1 which enter 
through a port other than the router's port are discarded. I believe the 
Cisco "IP address tracking" feature might be able to do that.

However a simpler approach may be to *detect* the problem: for example 
by running a tool like arpwatch on that network segment. Then you have 
an Acceptable Usage Policy which says that the manual configuration of 
IP addresses is *forbidden* and will result in serious consequences 
(make use of your company's or university's existing disciplinary procedure)

In my experience, the reason that people actually configure manual IP 
addresses is because the DHCP service is unreliable, and they are forced 
to do this to get work done. If that's the case, then the real solution 
is to make your DHCP service reliable.

It's fine to have two DHCP servers for redundancy:

interface Foo
   ip helper-address 192.0.0.1
   ip helper-address 192.0.2.2

The simplest way to make this work is to give the two DHCP servers 
non-overlapping pools of addresses (e.g. 192.168.1.10-149 and 
192.168.1.150-249). This avoids then need to run DHCP clustering where 
the two servers are both aware of each other's allocations. The user 
will receive two DHCP offers, will pick the first one and use that.

Also it's better if your lease times are sufficiently large (say 12 
hours) so that once they have an address at the start of the day, it 
works all day. For that to work well you might need bigger subnets, say 
a /22 instead of a /24, especially with wireless, but that's not a 
problem if you are using private IP addresses.

HTH,

Brian.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.bdnog.org/pipermail/nog/attachments/20151207/8ea75a16/attachment.html>