RE: Network "Change Management"
From: Bill Nash (billn_at_billn.net)
Date: 09/20/04
- Previous message: Fred Leeflang: "Re: Network "Change Management""
- In reply to: Jorge Reyes: "RE: Network "Change Management""
- Next in thread: Evan Pierce: "RE: Network "Change Management""
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 20 Sep 2004 12:48:45 -0700 (MST) To: Jorge Reyes <Jorge.Reyes@Talaris.com>
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
>
>
- Previous message: Fred Leeflang: "Re: Network "Change Management""
- In reply to: Jorge Reyes: "RE: Network "Change Management""
- Next in thread: Evan Pierce: "RE: Network "Change Management""
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
