The passive trap option is definitely better than an active poll.
Cisco's IOS-on-Catalyst handling of per vlan forwarding tables, with
regard to the SNMP engine, really makes polling for existing MAC entries,
in your bridge/forwarding tables, a super pain in the ass.
Alternatively, if handling snmp traps is too much admin overhead,
redirecting these traps to syslog output (where possible) would integrate
into existing syslog analysis engines (ala netcool, etc) with ease. While
I haven't tested it, it's likely possible to handle assigned MAC<->port
membership violations in the same manner. This is definitely behavior that
may change significantly between CatOS and IOS, or any of the hybrid
versions on various Catalyst platforms. Your mileage may vary, or be
recorded in kilometers.
- billn
On Sat, 18 Sep 2004, Jorge Reyes wrote:
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
