Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

not allowing protocol analyzers

We have Cisco switches and firewalls. Is there a way to not allow protocol analyzers to be used by employees on their workstations?

1 ACCEPTED SOLUTION

Accepted Solutions
Hall of Fame Super Silver

Re: not allowing protocol analyzers

Said

If an employee goes on a bad website, then multiple bad things could happen including the installation of unauthorized software - which might include a packet sniffer. But I do not believe that the routers or switches can detect the presence of software like that on workstations.

And duplicate TCP sequence number does not particularly indicate the presence of a packet sniffer. A packet sniffer just listens to traffic and does not interfere with traffic. The duplicate TCP sequence numbers are more likely caused by something that is requiring retransmission of TCP packets (lost packets or late arriving packets).

HTH

Rick

13 REPLIES
Hall of Fame Super Silver

Re: not allowing protocol analyzers

Said

Since the protocol analyzer runs on the workstation and just listens to traffic but does not transmit, how would you identify that it was present? Perhaps if you run NAC there might be some way to check for this, but otherwise I can not think of how you would enforce this using routers and switches.

HTH

Rick

New Member

Re: not allowing protocol analyzers

Rick, The firewall syslog message gave a 'duplicate TCP sequence number'. I am concerned. Is it possible to have an unauthorized outside source install a packet sniffer, by an employee going on a bad website?

Hall of Fame Super Silver

Re: not allowing protocol analyzers

Said

If an employee goes on a bad website, then multiple bad things could happen including the installation of unauthorized software - which might include a packet sniffer. But I do not believe that the routers or switches can detect the presence of software like that on workstations.

And duplicate TCP sequence number does not particularly indicate the presence of a packet sniffer. A packet sniffer just listens to traffic and does not interfere with traffic. The duplicate TCP sequence numbers are more likely caused by something that is requiring retransmission of TCP packets (lost packets or late arriving packets).

HTH

Rick

New Member

Re: not allowing protocol analyzers

Rick,

Thanks. I wanted to inquire if the firewall or switch could prevent protocol analyzer to enter network.

Said

New Member

Re: not allowing protocol analyzers

Rick,

Will upgrading the strings on an IPS during work hours interfere with the network? Should the IPS version be upgraded after hours?

Thanks.

Hall of Fame Super Silver

Re: not allowing protocol analyzers

Said

You asked:"if the firewall or switch could prevent protocol analyzer to enter network" and I do not believe that it is possible for the firewall to prevent a protocol analyzer from entering the network. This is mainly because protocol analyzers are not traffic that enters the network that a firewall might be able to stop. The protocol analyzer is software on a PC and a firewall can not prevent a PC from being connected to the network.

I would not think that upgrading the strings on an IPS would disrupt the network.

Thank you for using the rating system to indicate that your question was resolved (and thanks for the rating). It makes the forum more useful when people can read a question and can know that they will read a response that did resolve the question.

The forum is an excellent place to learn about Cisco networking. I encourage you to continue your participation in the forum.

HTH

Rick

Re: not allowing protocol analyzers

With a protocol analyzer connected to a switch access port, your user(s) are not going to have much visibility anyway, assuming reasonable precautions are taken to protect the switch/network from Layer 2 exploits (e.g.: CAM overflow, MAC Spoofing, etc.).

They'll see broadcasts, multicasts, and the occasional unicast packet that gets flooded before the switch associates the source MAC with a port.

New Member

Re: not allowing protocol analyzers

Micheal,

I am a new network admin. Bear with me, on a Cisco 2960 switch, which port is the switch access port? Ethernet is a broadcast technology. So if a hacker manages to install a rootkit on a workstation, will only traffic from and to the workstation be captured? there is a possibility that the rootkit has a protocol analyzer, yes?, id so if a switch has its own broadcast domain then traffic on other ports can not be observed,yes?

Thanks.

Said

Re: not allowing protocol analyzers

An "access" port is a port to which a host is attached, vs. a trunk port which would be used to interconnect two switches.

An "access" port is configured as such.

e.g.:

interface FastEthernet0/18

description Host-18

switchport mode access

Each switch port is a separate "collision" domain. This distinguishes a switch from a hub. With a hub, you would see all traffic (unicast, broadcast, multicast) from all connected sources.

All switch ports are in a common "broadcast" domain (assuming no VLANs).

A network sniffer connected to a switch port would permit you to see broadcasts, multicasts, and unicasts to/from your host.

Occasionally, you may see a unicast packet from a conversation other than your own when the switch floods a packet prior to associating the source MAC address with the switch port on which it was received (stored in a table).

A Layer 2 exploit exists (CAM Table Overflow) that could cause a poorly configured switch to fail-open, resulting in the flooding of all traffic out all ports.

A well designed, well managed network doesn't have rootkits, or protocol analyzers on its hosts. If discovered, that would suggest that administrators had failed to secure the network adequately.

There are many Cisco and industry standard features that can be utilized to secure the infrastructure.

Many of the configurations posted in these forums show a lack of focus on securing the infrastructure.

New Member

Re: not allowing protocol analyzers

Thanks for your explanation.

The ASA syslog server gave a Duplicate TCP sequence number message. I cleaned up the workstation associated with the above mssg. There was a rootkit on the workstation, which was removed. The destination was a company in Europe. The company in Europe has used different IP network addresses to send ICMP to the firewall. How would you suggest to prevent rootkits to be installed on computer on the LAN? We have an IPS module in the ASA firewall.

Re: not allowing protocol analyzers

A question such as that can't be fully addressed in a single post. I wouldn't suggest that I have "all" the answers either.

My earlier comments were meant to suggest that the Cisco feature set includes many security features that go un-utilized by many administrators.

You mentioned inbound ICMP traffic that concerns you. ACLs provide the means to define specific "types" of ICMP traffic that you wish to permit/deny based on security policy.

e.g.:

permit icmp any any echo log

permit icmp any any packet-too-big

permit icmp any any source-quench

permit icmp any any parameter-problem

ICMP responses can be controlled (no ip unreachables), ICMP inspection can be used, ICMP can be rate limited, Control and Management Planes can be protected, etc.

I'm not suggesting ICMP is the cause of your problem. I'm just using your reference to ICMP as an opportunity to expand on the idea that many security related configuration parameters go unexplored.

Perhaps the rootkit was introduced through the use of a USB flash drive, permissive web browsing behavior, lack of HTTP inspection (e.g.: RFC conformance, port 80 tunneling), or some other deficiency in security policy or user behavior.

I doubt there is a substitute for a well thought out, well executed security policy.

Many companies don't even restrict transit traffic to those specific protocols required by the business, and exclude all else.

There are many sources for security guidance. The following site has some configuration guides for Cisco routers, switches, etc., that may be helpful:

http://www.nsa.gov/snac/downloads_all.cfm

Glad to hear that you were logging, and that you were successful in removing the rootkit.

New Member

Re: not allowing protocol analyzers

Thanks.

Re: not allowing protocol analyzers

You're welcome.

The following site has benchmarks for Cisco devices etc., that can help you evaluate the security of your configurations.

http://www.cisecurity.org/

I have not explored these particular benchmarks yet, but they appear to be worth pursuing.

There are other such tools as well.

Might take a look at Nipper as well:

http://sourceforge.net/projects/nipper

198
Views
10
Helpful
13
Replies