[ietf86-tech] DHCP issue in tower 2

[Warren Kumari]

On Mar 10, 2013, at 11:13 PM, Warren Kumari <warren at kumari.net> wrote:

> I *think* I can block that….
> 
> I'll drop in another filter. Someone let me know (by phone if necessary - 571-969-4367) if things break after this change…

Been working with Colin, looks like all under control now.

We now have a Block_DHCP filter applied as part of the broadcast suppression filter that blocks DHCP replies on input from the guest network.

Term Block_Rogue_DHCP.

[edit firewall family bridge filter Block_Chatty_Protocols]
wkumari at RtrA# show
term NetBIOS {
    from {
        destination-mac-address {
            ff:ff:ff:ff:ff:ff/48;
        }
        ip-protocol udp;
        port [ 137 138 ];
    }
    then {
        count Discard_NetBIOS;
        discard;
    }
}
term mDNS {
    from {
        destination-mac-address {
            01:00:5e:00:00:fb/48;
            01:00:5e:00:00:fb/46;
        }
    }
    then {
        count Discard_mDNS;
        discard;
    }
}
term Wake_on_LAN {
    from {
        ether-type 0x0842;
    }
    then {
        count Discard_Wake_on_LAN;
        discard;
    }
}
term mDNSv6 {
    from {
        destination-mac-address {
            33:33:00:00:00:fb/48;
        }
    }
    then {
        count Discard_mDNSv6;
        discard;
    }
}
term Allow_ARP {
    from {
        ether-type arp;
    }
    then {
        count Accept_ARP;
        accept;
    }
}
term Block_Rogue_DHCP {
    from {
        ip-destination-address {
            255.255.255.255/32;
        }
        destination-port 68;
    }
    then {
        count Discard_Rogue_DHCP;
        discard;
    }
}
term Allow_DHCP {
    from {
        ip-protocol udp;
        port [ 67 68 ];
    }
    then {
        count Allow_DHCP;
        accept;
    }
}
term Block_Other_Broadcast {
    from {
        destination-mac-address {
            ff:ff:ff:ff:ff:ff/48;
        }
    }
    then {
        count Discard_Other_Broadcast;
        discard;
    }
}
inactive: term Block_non_RTR_ARP {
    from {
        ether-type arp;
    }
    then {
        count Discard_non_RTR_ARP;
        discard;
    }
}
term Allow_RTR_ARP {
    from {
        ether-type arp;
        ip-address {
            130.129.64.1/32;
        }
    }
    then count Allow_RTR_ARP;
}
term Block_non-matched_bcast {
    from {
        traffic-type broadcast;
    }
    then {
        count Discard_non-matched_broadcast;
        discard;
    }
}
term Allow_ND {
    from {
        destination-mac-address {
            33:33:00:00:00:00/16;
        }
    }
    then {
        count Allow_ICMPv6;
        accept;
    }
}
term Block_Other_mCast {
    from {
        traffic-type multicast;
    }
    then {
        count Discard_other_mCast;
        discard;
    }
}
term Block_unknown_unicast {
    from {
        traffic-type unknown-unicast;
    }
    then {
        count Unknown_Unicast;
        accept;
    }
}
term Default {
    then {
        count Default_Accept;
        accept;
    }
}


> 
> W
> On Mar 10, 2013, at 11:10 PM, Colin Doyle <cdoyle at verilan.com> wrote:
> 
>> Glen with AMS indicated to me this evening that the wired connection in room 2040 didn't seem to be working. The following address was being served:
>> 
>> "10.0.1.165 on wired., defaultgw 10.0.1.1"
>> 
>> After some troubleshooting, I got it working with a static at the very end of the 130.129.64.0/21 range (not sure what the scope is, but I'll check in the morning). I wiresharked the line and discovered the rogue DHCP server (see attachments). I'm not certain if this address is from the hotel or not, but I'm guessing that since the source is ID'ed as an Apple, it is a genuine rogue device.
>> 
>> We can discuss filtering/blocking in the morning. I suspect this will continue to be an issue until addressed, but I'm not sure what my reach is in this scenario without discussing with the rest of you.
>> 
>> C
>> 
>> (the DHCP file is wireshark output)
>> 
>> -- 
>> 
>> 
>> 
>> Colin Doyle
>> Senior Network Engineer
>> CCNA, F5 ASP/ATSP, Juniper JES
>> 
>> Verilan Event Services, Inc.
>> 7327 SW Barnes Rd. #215
>> Portland, OR 97225
>> 
>> 
>> Cell: 503 810-2129
>> cdoyle at verilan.com
>> www.verilan.com
>> 
>> 
>> This e-mail contains proprietary information and may be confidential. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you received this message in error, please delete it immediately.
>> 
>> <Screen Shot 2013-03-10 at 11.03.59 PM.png><DHCP>_______________________________________________
>> ietf86-tech mailing list
>> ietf86-tech at daedelus.com
>> http://www.daedelus.com/mailman/listinfo/ietf86-tech
> 
> --
> Some people are like Slinkies......Not really good for anything but they still bring a smile to your face when you push them down the stairs.
> 
> 
> 

--
Consider orang-utans.
In all the worlds graced by their presence, it is suspected that they can talk but choose not to do so in case humans put them to work, possibly in the television industry. In fact they can talk. It's just that they talk in Orang-utan. Humans are only capable of listening in Bewilderment.
-- Terry Practhett