RE: Network "Change Management"

From: Jorge Reyes (Jorge.Reyes_at_Talaris.com)
Date: 09/18/04

  • Next message: Fred Leeflang: "Re: Network "Change Management"" 
    Date: Sat, 18 Sep 2004 14:38:57 -0700
To: <focus-linux@securityfocus.com>

    FastEthernet and Ethernet interfaces on a Cisco switch support the generic link up and down traps defined in SNMP MIB II. This sample output was captured on an ATM inverse multiplexing over an ATM (IMA) network module. It used the debug snmp packet command to view the contents of the traps.

            3640-1.1(config)# interface ATM 2/0
            3640-1.1(config-if)# no shutdown
            3640-1.1(config-if)#
            *Mar 1 20:17:24.222: SNMP: Queuing packet to 171.69.102.73
            *Mar 1 20:17:24.222: SNMP: V1 Trap, ent products.110,
            addr 10.10.10.1, gentrap 3, spectrap 0
            
            !--- The gentrap value "3" identifies the LinkUp generic trap.
            
             ifEntry.1.1 = 1
             ifEntry.2.1 = ATM2/0
             ifEntry.3.1 = 18
             lifEntry.20.1 = up
            *Mar 1 20:17:24.290: SNMP: Queuing packet to 171.69.102.73
            *Mar 1 20:17:24.290: SNMP: V1 Trap, ent ciscoSyslogMIB.2,
            addr 10.10.10.1, gentrap 6, spectrap 1
             clogHistoryEntry.2.49 = LINK
             clogHistoryEntry.3.49 = 4
             clogHistoryEntry.4.49 = UPDOWN
             clogHistoryEntry.5.49 = Interface ATM2/0, changed state to up
             clogHistoryEntry.6.49 = 7304420

    Issue the show snmp command to confirm that the router sent a trap PDU.

            3640-1.1# show snmp
            Chassis: 10526647
            55 SNMP packets input
                0 Bad SNMP version errors
                16 Unknown community name
                0 Illegal operation for community name supplied
                0 Encoding errors
                37 Number of requested variables
                0 Number of altered variables
                2 Get-request PDUs
                37 Get-next PDUs
                0 Set-request PDUs
            55 SNMP packets output
                0 Too big errors (Maximum packet size 1500)
                2 No such name errors
                0 Bad values errors
                0 General errors
                39 Response PDUs
                16 Trap PDUs
            So you can configure your Linux Server to accept SNMP traps from the Cisco switch and page alert base on the trap value.
            UP/DOWN that is
            Jorge
             

            -----Original Message-----
            From: Zow" Terry Brugger [mailto:zow@llnl.gov]
            Sent: Thu 9/16/2004 12:24 PM
            To: Dave Torre
            Cc: focus-linux@securityfocus.com
            Subject: Re: Network "Change Management"
            
            

            Dave,

    > Does anyone know of a Linux utility that can watch the MAC address
    > tables in Cisco switches and alert admins as to when a new device has
    > been plugged in?

            I don't work with Cisco switches too much, however you may be able to
            configure it to send an snmp alert to your Linux box when a new device is
            plugged in. You'd then use snmp-util (or whatever it's called these days) to
            handle the message on the Linux side.

            Alternatively you can set up arpwatch on your Linux box and periodically ping
            your whole range of IPs. Arpwatch will alert you when it sees new or changed
            MAC addresses for those IPs.

    > Basically, we have your standard client network with DHCP. Internet
    > access is restricted to authenticated users, and so are the file shares.
    > However, we've had a few instances where people just plug in their
    > personal laptops which makes me very worried...

            Okay, then a couple other things you might want to consider:
            1. If it is a managed switch, you should be able to configure it to only
            allow MACs on a given list, hence preventing new boxes from even getting a
            layer 2 connection.
            2. Set up the dhcp server to only allocate IPs to certain MAC addresses.
            3. You should be able to get dhcpd to report to you when it allocates to a
            previously unseen MAC address (probably by throwing together some scripts to
            parse the log messages and comparing the MACs in them to a list).

            Of course, all of the above are assuming that someone isn't spoofing their
            MAC address to one that you allow on your network. Typically someone has to
            be deliberately malicious to do that though, so the above strategies
            (especially blocking based on MAC) are good for stopping people from
            connecting up their personal laptop and infecting the network with the worm
            du jure. The best prevention against MAC spoofing is to trust your users.

            Hope this helps,
            Terry


  • Next message: Fred Leeflang: "Re: Network "Change Management""