Re: [Security for] Analysis port for 3com 3300 was Re: (no subject)
Because this is a firewalls list, this thread can serve as a good segue into a question about switch security that has been on my mind for some time: Most switches support remote management features like web interfaces, SNMP, telnet, etc. If these switches hacked, someone can not only cause a denial of service, but use the port mirroring feature to sniff traffic. So, I am curious to know the thoughts of others in addressing this issue. (I know that some of the more expensive switches and routers can utilize encrypted passwords, but I believe community strings are still clear text, correct?) At 1/4/2002 12:10 PM, [EMAIL PROTECTED] wrote: With the 3com 3300, in order to monitor the network traffic that is traversing the 3com 3300 switch, one must configure what is called a monitor port or analysis port (under the Roving Analysis Setup) using the 3com Switch Management Software. One has to define an Analysis port (the port that is connected to the Sniffer) and a monitor port (the port that is being monitored). Once the two are defined, and it is enabled via the Switch Management software, the stack passes all the traffic going in and out of the monitor port and copies it to the analysis port. If you are attempting to monitor traffic across multiple VLANs, an analysis port must be setup in each VLAN used by the 3com 3300. Note: The analysis port should be configured to have a higher bandwidth than the monitor port, otherwise, not all traffic that is being analyzed will be captured entirely. /hope this helps /cheers, *useless memorization of switch/router configuration options.. * (these type of questions never appear on a CISSP exam.:-) /m At 11:53 AM 1/4/2002 -0800, William Stackpole wrote: Daniel, Most switches will allow one or more ports to be combined or cross connected for this very purpose. If this isn't possible then the best you can do is put the sniffer on the backbone segment attached to the switch. You wouldn't be able to see the traffic between individual switch nodes but you will be conversations out to servers, Internet connections etc. The other alternative, if this is a temporary situsation for troubleshooting purposes, you could replace the switch with a hub. -- Bill Stackpole, CISSP - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 04, 2002 11:14 AM Subject: (no subject) Hi, how do I use snnifer in a switch in a way that permits to capture all traffic ? (3com 3300) Thank's in advance, Daniel ___ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls ___ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls ___ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls * Kenneth H. Milder Los Alamos National Laboratory Computing, Communications Networking Division (CCN) Network Engineering Group(CCN-5) Network Support Team (NST)/X Division Computing Services Team (XCS) MS-F645 Los Alamos, New Mexico 87545-0010 Office: (505)667-2552 Fax: (505)665-3389 E-mail: [EMAIL PROTECTED] *
Re: [Security for] Analysis port for 3com 3300 was Re: (no subject)
On Wed, 9 Jan 2002, Ken Milder wrote: Because this is a firewalls list, this thread can serve as a good segue into a question about switch security that has been on my mind for some time: Most switches support remote management features like web interfaces, SNMP, telnet, etc. If these switches hacked, someone can not only cause a denial of service, but use the port mirroring feature to sniff traffic. So, I am curious to know the thoughts of others in addressing this issue. (I know that some of the more expensive switches and routers can utilize encrypted passwords, but I believe community strings are still clear text, correct?) My take- If you need to manage a switch, you've got WAY too much time on your hands. I've never put an IP address on a switch, and can't see any valid reason for doing so that isn't better done at some other level or via a different vector (such as a terminal server wired to console ports.) In-band management wasn't good for the phone system, and it's not good for IP networks. Paul - Paul D. Robertson My statements in this message are personal opinions [EMAIL PROTECTED] which may have no basis whatsoever in fact. ___ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
Re: [Security for] Analysis port for 3com 3300 was Re: (no subject)
I don't understand what you are saying. Are you suggesting that you simply unpack your switches and plug them into the network right from the box? Please don't say it's so, you've posted a lot of good thoughts in the past, and I can't believe you'd actually suggest that now. Bear in mind that a lot of switches out of the box grab an IP address via bootp all on their own, and also tend to have web management enabled with default passwords. IP addresses on switches are in my opinion a very good idea, because then I can monitor the traffic of each port on the switch, whereas otherwise I'd have to load snmp agents on each server. Not only that, but it's a very common management model in businesses to have separate WAN and LAN teams. The person monitoring the switches often doesn't have any administrative access to the servers. On Wed, 9 Jan 2002, Paul Robertson wrote: On Wed, 9 Jan 2002, Ken Milder wrote: Because this is a firewalls list, this thread can serve as a good segue into a question about switch security that has been on my mind for some time: Most switches support remote management features like web interfaces, SNMP, telnet, etc. If these switches hacked, someone can not only cause a denial of service, but use the port mirroring feature to sniff traffic. So, I am curious to know the thoughts of others in addressing this issue. (I know that some of the more expensive switches and routers can utilize encrypted passwords, but I believe community strings are still clear text, correct?) My take- If you need to manage a switch, you've got WAY too much time on your hands. I've never put an IP address on a switch, and can't see any valid reason for doing so that isn't better done at some other level or via a different vector (such as a terminal server wired to console ports.) In-band management wasn't good for the phone system, and it's not good for IP networks. Paul - Paul D. Robertson My statements in this message are personal opinions [EMAIL PROTECTED] which may have no basis whatsoever in fact. ___ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls ___ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
Re: [Security for] Analysis port for 3com 3300 was Re: (no subject)
Paul, Thanks for your comments. You must have a small network. We have several hundred subnets and thousands of nodes. Gathering traffic statistics, installing patches and software upgrades, trouble shooting, and other network management functions make remote management of our switches essential. It is inefficient to have a tech jump into a truck and drive 20 miles to a remote site every time we need to trouble shoot a compliant about poor network performance. Take care, -Ken At 1/9/2002 04:18 PM, Paul Robertson wrote: On Wed, 9 Jan 2002, Ken Milder wrote: Because this is a firewalls list, this thread can serve as a good segue into a question about switch security that has been on my mind for some time: Most switches support remote management features like web interfaces, SNMP, telnet, etc. If these switches hacked, someone can not only cause a denial of service, but use the port mirroring feature to sniff traffic. So, I am curious to know the thoughts of others in addressing this issue. (I know that some of the more expensive switches and routers can utilize encrypted passwords, but I believe community strings are still clear text, correct?) My take- If you need to manage a switch, you've got WAY too much time on your hands. I've never put an IP address on a switch, and can't see any valid reason for doing so that isn't better done at some other level or via a different vector (such as a terminal server wired to console ports.) In-band management wasn't good for the phone system, and it's not good for IP networks. Paul - Paul D. Robertson My statements in this message are personal opinions [EMAIL PROTECTED] which may have no basis whatsoever in fact. ___ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls * Kenneth H. Milder Los Alamos National Laboratory Computing, Communications Networking Division (CCN) Network Engineering Group(CCN-5) Network Support Team (NST)/X Division Computing Services Team (XCS) MS-F645 Los Alamos, New Mexico 87545-0010 Office: (505)667-2552 Fax: (505)665-3389 E-mail: [EMAIL PROTECTED] *
Re: [Security for] Analysis port for 3com 3300 was Re: (no subject)
On Wed, 9 Jan 2002 [EMAIL PROTECTED] wrote: I don't understand what you are saying. Are you suggesting that you simply unpack your switches and plug them into the network right from the box? No, I'm saying that I've always tried to avoid plugging in a switch which was configured to talk IP on a production network (Ciscos used to come out the box that way- I tend to buy cheaper/dumber devices these days.) IP addresses on switches are in my opinion a very good idea, because then I can monitor the traffic of each port on the switch, whereas otherwise I'd have to load snmp agents on each server. Not only that, but it's a very common management model in businesses to have separate WAN and LAN teams. The person monitoring the switches often doesn't have any administrative access to the servers. It's been probably 8 years since I've done anything with snmp that didn't count as turning it off. When I've needed to check the status of a server's service, I've done it by checking the actual service itself. When I've needed to check on equipment, I've done it through the console port wired to a terminal server to get away from in-band management issues. The single time I've been mandated to build in management, it got its own network (it was a router cloud- the switches still didn't get IP addresses.) To me, the benefit argument in the cost/benefit/risk analysis hasn't ever met the bar for managing switches. Buying more devices and building redundancy in up-front, or buying cheaper devices and cascading new gear in before anywhere near the MTBF both seem to me to be much better solutions than in-band managment. Unlike MAUs, CAUs and LAMs, I think I've only seen two Ethernet switch failures ever, and one was DOA. I've never been a huge fan of the router/switch/cusinart devices either though... Paul - Paul D. Robertson My statements in this message are personal opinions [EMAIL PROTECTED] which may have no basis whatsoever in fact. ___ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
Re: [Security for] Analysis port for 3com 3300 was Re: (no subject)
On Wed, 9 Jan 2002, Ken Milder wrote: Paul, Thanks for your comments. You must have a small network. We have several I've built and run networks from the tens of devices to the tens of thousands. hundred subnets and thousands of nodes. Gathering traffic statistics, installing patches and software upgrades, trouble shooting, and other network management functions make remote management of our switches essential. It is inefficient to have a tech jump into a truck and drive 20 I've seen two switch failures on switches I've procured since Ethernet switches became popular, one was DOA, and the other was locked up so that you couldn't remotely access it. If you've got any significant number of switch failures, then either your vendor needs a good dressing down, and your POs need a MTBF clause, or you're under capitalizing your network infrastructure. If it's a dumb switch, there's no need for software upgrades or patches. That leaves troubleshooting- and other than one set of Ethernet cards doing poor autonegotiation, I've yet to see a significant layer 2 problem on Ethernet which wasn't easily troubleshot without SNMP or switch stats- and most of those could be shot from either a host or a router. miles to a remote site every time we need to trouble shoot a compliant about poor network performance. If you're troublshooting performance issues on a regular basis, I'd suggest that your efforts really need to be directed towards building out a more robust architecture, or educating your users to build network infrastructure dollars into new projects to support their workloads. Networking existed pretty happily before people put SNMP on switches, even large robust networks. It's been my experience that most of the time, the very cause of trouble is the network layer, so once again, in-band management sucks for diagnosing it. That's why I like terminal servers wired to console ports where remote diagnosis is necessary. Another more useful trick if you're using large core switches is to out-of-band the console port and keep a sniffer on one port that you can span onto one of the VLANs. Sniffers are a heck of a lot more useful for diagnostics than built-in switch statistics IMO. FWIW, I've never had responsibility an internetwork with more than ~3,000 local users, and about 150 remote sites. Paul - Paul D. Robertson My statements in this message are personal opinions [EMAIL PROTECTED] which may have no basis whatsoever in fact. ___ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
