If you’re in my business of looking at logfiles to be able to determine what’s going on or what has happened one of the most annoying, and frightening, things to see is a sheer amount of failed login attempts. In most cases these are simply genuine mistakes where a lingering management application or forgotten script is still trying to login to obtain one piece of information or another out of the switch/fabric. The SAN switches are often well inside the datacentre management firewalls so attacks from outside the company are less likely to occur however when looking at security statistics over the last decade or so it turns out that threats are more likely to originate from inside the company boundaries. Employees mucking around with tools like nmap, MITD software like cane & able, or even an entire Kali Linux distro hooked up to the network “just to see what it does because a mate of mine recommended it”. In 99.999% of all install bases I looked at the normal embedded username/password mechanism is used for authentication and authorisation. This also means that if security management is not configured on these switches, a not so good-Samaritan is able to use significant brute force tactics to try and obtain access to these switches without anyone knowing. When using an external authentication mechanism like LDAP or TACACS+ chances are there are some monitoring procedures in place which monitor and alert on these kind of symptoms however the main issue is that the attack has already occurred and there is no mechanism to prevent these sorts of attacks on a level that really protects the switch. It is fairly simple to overload a switch with authentication attempts by firing off thousands of ssh,telnet and http(s) sessions (which is easily done from any reasonable priced laptop these days with a Linux distro like Kali installed) and therefore crippling the poor e500 CPU on the CP. This can have significant ramifications on overall fabric services in that switch which can bring down a storage network. Now, obviously there is a mechanism to try and prevent this via iptables however there are a number of back-draws.
Tag CloudBNA bottleneckmon brocade buffer credits cisco cloud data centre decoding disk encoding errors Ethernet event fabric fabrics FabricWatch FCoE fibre channel fillwords fill words firmware FOS future hba HDS Hitachi isl linux maintenance management MAPS microsoft open source optical performance resilient security SFP storage support switches T10 T11 VMware zoning