Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

I've had some visibility to big networking equipment manufacturers... the security or even stability on their web interfaces is terrible. It's like a strange rule of thumb for all the networking equipment manufacturers. If you have choice, disable the web interface.


sort by: page size:

I think network security best practices addresses that issue. Keep network management interfaces off unrestricted local area or routeable networks. Huge swaths of popular software as well as very expensive hardware have many unresolved security issues. There is nothing you can do to make a lot of that stuff secure short of putting them on their own isolated network and explicitly controlling all ingress/egress traffic to it.

Security best practices have always recommended treating all networks as untrusted and having non-internet-hardened stuff turned off by default in network facing products. You're right of course too, but Cisco is the real bad guy here.

>explicitly built

Just because a network interface is part of the hardware design does not make it "explicitly built" for use on the internet. On the software side 99.999% of these products are a security mess and only manage to dodge that reputation because the market is so fragmented that automated ways to bypass the security on these devices with no fine tuning involved does not yet exist.


I think I had the same one. Seriously, it feels like networking hardware is the armpit of the industry. A place where "approximately functional as long as you reboot it weekly and don't use any of its advertised features" appears to be considered good enough by their QA.

Now if only they took security seriously...

A few years ago I reported a problem to them that they told me wasn't a problem. For many years their IPMI hardware would automatically switch to the primary motherboard ethernet interface if the IPMI dedicated ethernet port wasn't active at boot, and in spite of an overabundance of jumpers, there was NO WAY to physically disable this.

You couldn't disable this in the BIOS settings, either. There was literally no setting or settings, anywhere, to disable or configure this. The closest there was to avoid IPMI compromise if you intended to use your primary ethernet for public Internet was to configure the IPMI to be on a VLAN that hopefully nobody could guess.

In order to configure the port to always stay on the dedicated IPMI port, you had to have a full network setup and the ability to run a browser compatible with their management junk. Or, you had to make sure the IPMI port was ALWAYS active. To do this in hardware, the best thing was to install a hardware loopback jack in the IPMI ethernet, which is what I ended up doing for Supermicro machines all over the planet.

Even if you use a browser to configure the BIOS settings, your machine is a failed BIOS battery away from possible compromise. I've seen instances where shipping machines via air cargo involved temperatures cold enough to cause BIOS settings to get lost.

Perhaps all of the clients they care about are running enough servers in datacenters to justify separate racks and cages with separate, dedicated, physically safe networks... But some people and smaller businesses colocate one or just a few servers at a time, and the thought of being a dead battery away from 100% complete compromise is just... Well, it's stupid, to be honest.

They said it wasn't a problem that concerned them, so they weren't going to fix it.

Sounds about right for a multi-billion dollar company, now that I think about it.


"It's really inexplicable. They have nice industrial design, good brand recognition, no shortage of money behind them, and they screw up at every conceivable turn."

Ipso Facto. They can't not screw it up.

A critical component of infrastructure should not be IP addressable. It should not be "on your wifi". It should not have a login or a password. It should be as dumb as possible and as simple as possible - and as anti-fragile to all of these events as possible.

It's not possible to have this "feature set" and not have this pain. It's a fools errand to pursue it.


You might want to put your security system and other infrastructure hardware on a separate VLAN.

Not only does that help prevent stuff like this, it turns out that a lot of embedded hardware isn't that great from a network security perspective.


It's also a security nightmare unless you are trained network engineer who can configure the thing properly.

Yep, I work with some old industrial hardware, and most of it is stuck in the year it was made and never upgraded... rs232, rs485, telnet, etc., is a thing you see very often. Now with modern networks, you can isolate those machines and the machines controlling/monitoring them pretty efectively, so those segments never touch the internet, but you still need to connect to those devices and use them. Telnet and rs* just work, because noone complained about zero security there and wanted them removed... but now we're removing stuff that's still in use on newer devices that are not even at hal their 20, 30, 40year lifespans.

I understand the security aspect, I know that telnet is insecure, but I know when, how and why it's insecure and use it accordingly... just add some -use-bad-crypto flag, maybe even make it as a module/plugin, and leave it working as it did.


Same. I'm a CCIE and after a five minute skim I can't tell if this is grandstanding or an actual threat. Best practice is to disable CDP on all eternal interfaces. This is a given.

There are no diagnostics you can perform from the web interface. You can't tell how the VLANs are configured on the other side of the network. There is nothing of value on the web interface. The only times I have looked at the web interface was during initial evaluation of the platform -- everything that matters is on the OLT and is not accessible from the ONU.

By break it, I mean that people who poke around at the ONU are likely to break something on the fibre side while satisfying their curiosity. Every time you pull the connector out you run the risk of getting dirt on the fibre, and if you're $joerandomenduser you're probably not going to clean it. Or you won't push the connector all the way in, or... there are more ways for you to break things than fix them when you don't know what you're doing. Please don't touch the fibre, as I don't want to have to charge you for a $200+ truck roll caused by your cluelessness. And yes, a truck roll really does cost more than $200 when all the travel time, fuel, tools and equipment costs are accounted for.


That is the whole point of this fuss, though. Way too many systems, from nuclear plants to manufacturers to traffic controllers are exposed to the internet (often through backdoors in LANs) and are vulnerable to network exploits.

It is the faults of the designers they make them visible like that, but they do it, and it is an issue.


I've seen multiple security audits that didn't see fit to mention such ethernet ports as a problem. I don't know why; it's possible management told them it was "out of scope".

When will people learn that industrial control systems can't ever be safely connected to the internet.

i've always assumed they were the least secure of all my networking hardware

Fair enough, there's always a shitty corporate network that'll mess with your well-designed protocol.

It's quite incompetent and negligent to put network connectors on servers that cause spectacular failures when exposed to a network.

This isn't a fair assessment of the situation. Networks that aren't entirely trusted and controlled can cause spectacular failures. By knowing this, administrators can use BMCs safely. My Poweredge server even came with a warning sticker that had to be removed before the DRAC port could be used.

In general, tools can have "pointy parts" with which the user could harm themselves so long as the risks and proper uses are documented and explained adequately.


Rockwell definitely has some questionable security on individual products, but they partnered with Cisco for their Converged Plantwide Ethernet Design [0] which is actually pretty well thought out, and if implemented properly covers off most of the biggest risks. The problem is either that people don't know about it, don't bother to read it, or can't get organizational buy-in to implement it.

When downtime is expensive, the pressure from the business is to err on the side of being able to get experts in to troubleshoot the system as easily as possible, vs guaranteeing that bad guys can't get in. The first they see all the time, and the second seems unreal until it actually happens...

[0] https://literature.rockwellautomation.com/idc/groups/literat...


Tangential, but are Fortinet products annoying as well as dangerous? What should I tell a boss who is considering their devices in front of their ISP line?
next

Legal | privacy