Any other actual router jockeys out there, aside from the folks just talking about it? I used to do BGP support at a regional ISP but I got out of that game almost a decade ago. Dead end job, dead end company, dead end industry, low pay, and 24x7 on call. Of course it doesn't have to be that bad.
Anyway, the doctrine pushed at the time by cisco was embedding a password into a router was only for home or VERY small business users. Anyone with more than, say, 4 routers or so should be using some form of network authentication.
We had network auth in the very early 00s although all our routers had an emergency console password configured in (had to use it once, looked like 80 characters of line noise, maybe it was). That was in a sealed envelop in a lockbox. Because he had to update every router manually if that envelope opened, our one security guy got pretty annoyed if anyone ripped the envelope open.
Anyway the point that might be missed is in a carrot and stick method, this might be a very extreme application of the stick to get people to use network AAA systems instead of configuring their console and enable passwords in each router.
I guess modern cisco routers/IOS can do LDAP and KERBEROS its not all RADIUS from 1993, although old stuff does work.
I will say that in the dark days before we went network AAA it was an absolute nightmare when someone on the team quit and someone had to go manually thru every router on the network and change the passwords and distribute the new one to us all.
This will negatively impact people with 1990s architecture, but to the extent that they're already in a living hell anyway it won't be much worse.
Unfortunately I've worked at a few places with non-internet connected routers (or so they thought, anyway) where documentation was so poor you basically had to break in each time you needed access. Physical access to do hard recovery via a reboot was a PITA. Making it "easier to break in" would be seen as a feature not a bug in those locations.
This is true - RADIUS and TACACS are the most secure way to access routers. I've found that nearly all routers in nearly all environments still have a local authentication. If you were to remove all network connections (or just the right one) you no longer have access to the authentication server and you would be totally locked out of the box since it doesn't cache any of the authentication. The running configuration of the router IS what you have to secure, and it needs to be stored under lock and key (SFTP, authenticated file share, etc). If you're sending it to non-shared parties you should remove the authentication from the configuration either manually or with 'show run brief'.
Most Cisco gear I've worked on (not ISP level) is extremely susceptible to local "attacks". I've never seen "disable-password-recovery" turned on in a config, and I've gone in and changed the CONFREG values dozens of times in order to grab an old config which no one knew the password too.
I always assumed that Cisco kind of passed off physical security to the owners of the equipment, which actually made some sense to me, as long as the users were aware that the device wasn't physically secure.
I can say with certainty there still remain tons of network infrastructures in the enterprise space who fail to comprehend the value of AAA. They still send router passwords around in plain text files. It really pains me to see how slowly enterprise customers adapt to operational trends (why change?, things have worked so far! facepalm)
The amount of routers still using 'cisco/cisco' as a default password for full access is astonishing. Years ago, I saw backbones and OC3/12 cores using these passwords.
I know botnets are now considered the DDOS standard, but there are plenty of remotely controlled Cisco routers that can pump out more data than hundreds of thousands of bots.
My favorite is outer nodes that can get user access with "cisco", then, full access to an inner node using "cisco", then, reconnect to the outer node (from inside), and have full access. Vicious circle.
Not supprised and happens, almost as good as cut and paste admin flaws that happen. Still the humour of a program in C that looks for insecure routers and uses strcpy is not lost on me :).
True of many equipment using default user/pass combo's, perish the thought they forced a change upon bootup/configuration, but that should of been covered by CISCO admin 101 school. AS/400's, heck anything with default accounts can end up with those accounts left, the sight standard user admin acocunts installed and maintained to password standards with the out of the box ones still there.
Then we worry about home routers with default admin accounts - oh the humour of it all. Some managment will think CISCO - thats expensive so it is more secure and they can get cheap staff in. Well you see what happens then.
The worst part about this is that there is no default password. It's marginally worse than doing nothing - people just voluntarily use cisco/cisco because they don't care about security.
* technically on some of the newer routers and versions cisco/cisco is a default, but after the first login it's no longer valid.
but there are plenty of remotely controlled Cisco routers that can pump out more data than hundreds of thousands of bots
Have any examples? I would think that a router is less than ideal here, as most forms of traffic generation would involve the anemic CPU and control/mgmt plane.
I'm just speaking from experience from a few of the older IRC botnets I analyzed for a few years. Nearly 200,000 of the 750,000 (+-150,000) bots were on dial-up connections in developing countries.
Now, 200,000 packets coming in at 2.8KB/s is nothing to joke about(500MB/s). Yet, 500 packets coming in at 8MB/s, well, on top of the arsenal of random connections.
I sometimes forget I'm a dinosaur now when it comes to this sphere of knowledge! I'm sure these days its less one sided. It used to be dialup and windows 95/98 RPC vulnerabilities spreading in the wild using IRC as a middleman.
With tor, torrents, etc, I imagine the game has drastically changed in the past 6 years. It is too bad there are not many jobs in this field, I would gladly make a lifetime out of it.
I was on a team that created an anti-bot-net which would reinfect, secure, and alert of the already infected machine. We determined that it could prove to be more destructive than the original botnet, because it wastes resources, while we could actually impact the way a machine behaved for the owner. This could also lead to legacy machines failing due to windows updates or firewall rules.
> I was on a team that created an anti-bot-net which would reinfect, secure, and alert of the already infected machin
While I'm sure your intention was benevolent, I'm pretty sure that's illegal under current laws. There's probably a reason that reputable AV vendors don't use that practice; I would hate to have unknown entities helpfully "patch" my machine.
If I were a bad guy I would enter a single config line static routing some "chunk of the internet" at the victim. That loss of production traffic would likely be rather quickly noticed... but for a little while it could be pretty impressive.
Lets say you have a content provider (as opposed to an eyeball provider) and it hosts nothing in Chinese. So nearly all traffic from APNIC netblocks is botnets and spammers WRT your content so your firewall normally would dump it all. However an attacker could static route several /8 APNIC blocks to someone or something and all you'd notice is your firewall discarding less. Of course the poor guy its all static routed to (perhaps one of your own systems?) would see some weird stuff incoming.
Someone who knows what they're doing could have a lot of "fun" with a BGP speaking router depending on how intelligently its peers are configured.
And if tomatoes were cows then we could milk them. Neither of these facts is terribly relevant to the world we live in; this is a serious security flaw.
If everyone uses long random passwords and never reuses them elsewhere, maybe it's optimal for simplicity and server-side cpu usage. There's no difference (edit: should say advantage rather than difference) in salted passwords (salt + shorter-randompassword) compared to (longer-random-password); salts become unnecessary since you can effectively guarantee that two users won't share the same password if they're all random and separately chosen.
However, the real world called and it wants "suboptimal" choices back, for when users don't use good password hygiene.
"guarantee that two users won't share the same password"
routers with hard coded passwords in the config don't have users. Device passwords. Often the console/telnet and enable password are the same so there is "a" password.
Of course you could implement as a network admin a psuedosalted standard like our router password shall be prefixed with hostname, "hostnamereallylongcomplicatedpasswordthatsthesameforallhostnames" then rainbow tables will barf because each individual device password begins with a different hostname, even if all of them end with the same "l33tpass0rd" or whatever.
This is assuming you have a sensible hostname strategy, or even assign "real" hostnames to your routers. I suppose people like that who haven't caught up to that newfangled "DNS thing" could use a unique router ip addrs, although now we're assuming a sensible ip allocation scheme and network design. This is kind of reading like Dante, isn't it.
Sure there is a difference. If there is another exploit that gets you hashed passwords from many thousand different routers you would be quite happy knowing that none of them were salted.
Also there is a huge difference between (salt + short-random-password) and (long-random-password) because the salt isn't nearly as confidential as the password and knowing it reduces the attack vector to (short-random-password), which is trivial to break for such poor (in this context) hash algorithm.
Which is not really a great assumption to make - people have been using weak passwords for decades against advice to the contrary, it's likely that isn't going to change in the short term.
It's not a 'switch' but rather failed implementation.
As well, this is only protecting people that would have otherwise put their saved passwords into insecure locations - like posting to the internet or insecure internal file shares.
For public posting the command 'show run brief' will take out all certificate and password information, at least for IOS-XE. NX-OS, IOS, and security IOS have options as well, use 'show run ?' to confirm.
Some orgs go to great lengths to segment access to their networking core and establish separation of privileges using AAA, etc. As well, configs can leak out through other means (TAC case, submission to auditors, etc).
Someone who has access to config backups shouldn't be able to bootstrap their privileges by cracking passwords.
In theory "audit our config backups, and fix them up" is a task you can assign to a junior network engineer with a limited account and a copy of RANCID.
Role separation, defense in depth, and all that...
Anyway, the doctrine pushed at the time by cisco was embedding a password into a router was only for home or VERY small business users. Anyone with more than, say, 4 routers or so should be using some form of network authentication.
We had network auth in the very early 00s although all our routers had an emergency console password configured in (had to use it once, looked like 80 characters of line noise, maybe it was). That was in a sealed envelop in a lockbox. Because he had to update every router manually if that envelope opened, our one security guy got pretty annoyed if anyone ripped the envelope open.
Anyway the point that might be missed is in a carrot and stick method, this might be a very extreme application of the stick to get people to use network AAA systems instead of configuring their console and enable passwords in each router.
I guess modern cisco routers/IOS can do LDAP and KERBEROS its not all RADIUS from 1993, although old stuff does work.
I will say that in the dark days before we went network AAA it was an absolute nightmare when someone on the team quit and someone had to go manually thru every router on the network and change the passwords and distribute the new one to us all.
This will negatively impact people with 1990s architecture, but to the extent that they're already in a living hell anyway it won't be much worse.
Unfortunately I've worked at a few places with non-internet connected routers (or so they thought, anyway) where documentation was so poor you basically had to break in each time you needed access. Physical access to do hard recovery via a reboot was a PITA. Making it "easier to break in" would be seen as a feature not a bug in those locations.