This device wouldn't create an issue of broadcast storms -- if someone from the IT department gets a request that user XYZ needs an additional data jack, they're going to make it happen one way or another.
A management hassle in my opinion will be duplex mismatches. Imagine these scenarios:
"Standard Wiring Topology"
In the "standard" configuration, a client PC is connected to your MANAGED workgroup switch. The network administrator configures the switch to Auto speed/duplex negotiation and the other link partner (the client PC in this case) is also configured for Auto speed/duplex negotiation. We'll assume they now run at 100/Full duplex. Now, if one of the link partners (either the switch or PC) is hard-coded to 10/Full duplex or 100/Full duplex, auto-negotiation will fail, resulting in a duplex mismatch. This will cause runts, FCS errors, and late collisions on that collision domain.
In order to fix this scenario, you can monitor the switch port for errors, diagnose the problem, and resolve the issue.
"3Com's Environmentally Friendly Topology"
Your MANAGED workgroup switch is configured for Auto speed/duplex negotation, which is connected to an auto-negotation port on the wall switch. However, as soon as XYZ user plugs in a hard-coded device, you'll have connectivity issues. Except now, because it's an unmanaged switch, you have no way to diagnose it.
While I would agree that this is not something a firewall is *supposed* to do, it's not entirely true that a firewall *won't* protect you.
While trying to recover from this kind of worm (cleaning the systems of your internal workstations), they are spewing forth a crapload of requests out to the world. It makes sense that you may want to have your firewall block these requests from leaving your company, as to not piss off the internet world.
I'm sure this is true with a few other firewall products out there, but at least with Check Point Firewall-1, I enabled the content security filters to drop HTTP packets using the GET method with cmd.exe, root.exe, readme.exe, readme.eml, admin.dll, and default.ida in the string. This effectively blocked malicious outgoing packets until we are sure the internal systems have been sanitized.
Slashdot Mirror
This device wouldn't create an issue of broadcast storms -- if someone from the IT department gets a request that user XYZ needs an additional data jack, they're going to make it happen one way or another.
A management hassle in my opinion will be duplex mismatches. Imagine these scenarios:
"Standard Wiring Topology"
In the "standard" configuration, a client PC is connected to your MANAGED workgroup switch. The network administrator configures the switch to Auto speed/duplex negotiation and the other link partner (the client PC in this case) is also configured for Auto speed/duplex negotiation. We'll assume they now run at 100/Full duplex. Now, if one of the link partners (either the switch or PC) is hard-coded to 10/Full duplex or 100/Full duplex, auto-negotiation will fail, resulting in a duplex mismatch. This will cause runts, FCS errors, and late collisions on that collision domain.
In order to fix this scenario, you can monitor the switch port for errors, diagnose the problem, and resolve the issue.
"3Com's Environmentally Friendly Topology"
Your MANAGED workgroup switch is configured for Auto speed/duplex negotation, which is connected to an auto-negotation port on the wall switch. However, as soon as XYZ user plugs in a hard-coded device, you'll have connectivity issues. Except now, because it's an unmanaged switch, you have no way to diagnose it.
Unless you download "ME" from his FTP warez si... oh nevermind...
While I would agree that this is not something a firewall is *supposed* to do, it's not entirely true that a firewall *won't* protect you.
While trying to recover from this kind of worm (cleaning the systems of your internal workstations), they are spewing forth a crapload of requests out to the world. It makes sense that you may want to have your firewall block these requests from leaving your company, as to not piss off the internet world.
I'm sure this is true with a few other firewall products out there, but at least with Check Point Firewall-1, I enabled the content security filters to drop HTTP packets using the GET method with cmd.exe, root.exe, readme.exe, readme.eml, admin.dll, and default.ida in the string. This effectively blocked malicious outgoing packets until we are sure the internal systems have been sanitized.