Heck, some cloud providers have password logins by default. Since the instances are easy to setup I'd imagine many companies operating with a no-ops situation are vulnerable and don't even know it.

And then there are side projects. I remember being educated enough to know better, but doing it anyway as the server was a $5 digital ocean droplet, used to run a tiny minecraft server for some friends. Got brute forced and spent the next two weeks red-faced, trying to get DO to allow network access again so I could at least grab a backup before nerfing the droplet.

Now I use a basic ansible setup to automate changes to sshd so I don't have any excuse to be stupid again.

Not sure what you're arguing here. You either have control over sshd or you don't. Or are you really suggesting you can change the port of sshd but aren't allowed to disable password auth?

I'm a software engineer, so if my company gets hacked via ssh that's really not my problem. Worrying about such things would make me a busybody. But if you're a system admin and can't properly do your job, then I would seriously start looking for a new place to work. They will get hacked and you will be the guy that gets blamed.

> Not sure what you're arguing here. You either have control over sshd or you don't. Or are you really suggesting you can change the port of sshd but aren't allowed to disable password auth?

First, you'll have to separate two things here. One is the technical ability to control sshd, the second whether a company will allow you to tinker with the auth policy (whether that is password login, password login with only strong passwords, or rsa/ecdsa key access only).

The latter has nothing to do with control and only with what decision makers allow you to do (that sometimes is a large product vendor, not allowing anything beyond what they ship). If you work in a place where you have full control over the systems you work on, great for you. I can ensure you that it is not the norm (unless we're talking about hobby projects or projects with exclusive personal ownership).

As for the technical aspect, keep in mind that changing the public facing ssh port might not even be done on the host itself, but e.g. in port forwarding table in a router/firewall. This might not even always happen because it's technically impossible to do it on the box itself.

I'm pretty certain that tinkering with a box is regularly discouraged (especially if it is managed by some orchestration or vendor specific control/update tool), while effectively the same can be done by changing a router/firewall. There's a lot more things to be said about that, but please take it from me that hacking around in a systems you have not build yourself isn't always a bright idea (and it happens to be a very common situation).

> But if you're a system admin and can't properly do your job, then I would seriously start looking for a new place to work.

That's an interesting theory, but frankly not how I think the real world (usually) works. As a system admin you are there to solve problems for a client or employer. You can (and should) of course always warn for potential dangers, but refusing work or quitting a job/assingment because you're not getting full control over a system .. good luck with that. It is simply not an acceptable position in many situation. You must be in really high demand if you want to pull stunts like those and still have any work after a while.

Maybe it works different in software engineering land, but I highly doubt it. When was the last time you quit a job, because you preferred a different library or framework over the one your superiors/client dictated?

Please don't get me wrong. On a personal level I'm very principled about what I choose to work on or with (and what I refuse to take part of). But at the end of the day we are professionals, here to solve problems. If we can and a client/employers is willing to accept the risks of an imperfect solution that fits in their requirements, it ultimately is their call and responsibility. All within reason, of course.

> tinker with the auth policy (whether that is password login, password login with only strong passwords, or rsa/ecdsa key access only).

Or the port ssh works on

> that sometimes is a large product vendor, not allowing anything beyond what they ship

Surely you'd limit access to that on an IP level and bounce via a bastion (which you do control)

> tinkering with a box is regularly discouraged (especially if it is managed by some orchestration or vendor specific control/update tool), while effectively the same can be done by changing a router/firewall

"Tinkering" with a router/firewall sounds far more dangerous than a box -- you can knock out 2000 machines in one go.

> That's an interesting theory, but frankly not how I think the real world (usually) works

If the shit hits the fan, are you confident your management (which apparently refuse to allow you to implement basic security policies) will have your back, or will they pile the entire blame on your to save their skin.

Better to look for a company that respects your skills before you get pink slipped.

> Or the port ssh works on

Calling that part of the auth policy (in the context if was responding to) is a bit of a stretch, but okay.

> Surely you'd limit access to that on an IP level and bounce via a bastion (which you do control).

What percentage of organizations have you seen do it that way? In my experience it's more often directly behind an internet facing NAT router, through a port forward. I'm not saying that's a good thing, I'm saying it's reality.

> "Tinkering" with a router/firewall sounds far more dangerous than a box -- you can knock out 2000 machines in one go.

You again appear to be missing the point I tried to make. It's not so much about danger, but more about control. A box is regularly far more of black hole (especially if it's a vendor appliance or legacy system) than a company's router/firewall is. Sure not without dangers, but that's why you're a professional that (hopefully) knows what he/she is doing. How often did you work on a router/firewall that controlled 2000 machines? In my case, I can count those on one or maybe two hands.

> If the shit hits the fan, are you confident your management (which apparently refuse to allow you to implement basic security policies) will have your back, or will they pile the entire blame on your to save their skin.

It works a bit different if you're contracted or working for clients, but either way: that's why you document things and make clear to those who make decisions that the risks are theirs and not yours.

--

But seriously though .. I'm not sure if you genuinely missed the point(s) I tried to make, if you might be pedantic on purpose (just for the sake of it), if you might be just another armchair general, or maybe have only worked in very privileged positions where you had full control and authority over the systems you had to deal with. The latter is certainly not the reality I've experienced for over two decades.

Maybe you are experienced, just in a very different reality/industry than mine. Still, I find these kind of arguments about companies "not allowing you to do basic security" or "not respecting your skills" rather childish and out of touch with the reality. I have not seen many gigs/companies where sysadmins (or even -architects) have this kind of god-like status. When I did see such situations, it often meant a company would have serious (potential) issues if/when their "guru" would piss off (leaving a collection of equipment in "status unknown", i.e. the next guy would not be allowed to touch anything and ergo my point about tinkering with boxes being discouraged).

How long have you been doing this (professionally)? That's not a rhetorical question. I'm genuinely curious.

Network administration (and system administration of about 150 linux machines) for about 10 years. I did a full port sweep of my network a few days ago, 1,555 IPs with port 80 open (although to be fair several of those are multi-IP connected). Before that 7 years of system administration and development.

My (my team's) network policy is that those web ports are not exposed on the internet - we provide proxies with 2 factor authentication up front. We find we get far happier users when we use carrots.

We operate a high wall policy, and while we do push towards a secure-everywhere system, we are more flexible that other corporate networks, and tend not to have exacting requirements. Your black box wants to use SNMP v2? Of course it does, that's fine. No you're not probing it from the internet though, we'll work with you to increase security.

If a team want a device that claims to run a proprietary protocol and needs TCP ports from the internet, that's fine, we do it. We discovered recently one of these devices was actually running a standard webserver on one of these ports after a firmware update. The device user didn't even know.

Ultimately we provide a network, you can take it or leave it, there's competition (go for one of the two non-shadow IT networks, or build your own).

I know from personal experience what happens when things go bad against my teams advice, all those emails saying "this will go bad" are work jack squat. Fortunately we had very air support for that specific event (front page national news), nobody cares about "I told you so".

Fair enough. Clearly not a greenhorn.

From the context of your description, your earlier arguments certainly make more sense, more than they would in the situations I'm personally more familiar with.

My main conclusion here is that we are both referring to very different (work) environments.

For what it's worth, given the context you've described, I can well understand and support your arguments.

That said, I'm not so sure your context is representative of the industry as a whole. To be fair, I really don't know what would be. Only that we apparently have worked in very different environments with very different conditions and requirements.

Just to be clear: when I argued about warning for the risks of particular choices, I was never referring to internal company communications. Those are indeed worth little to nothing (if shit happens). I was referring to communication between separate legal entities. Withing B2B contract work, such communications do quickly become crucial (if shit happens), even from a legal perspective.

I hope you can see that while your arguments do hold well within the world you know, they might not be so applicable or useful in other (certainly existing) situations. The world certainly is more diverse than the context you've given.

Kind regards, and thank you for answering my question.

> Withing B2B contract work, such communications do quickly become crucial (if shit happens), even from a legal perspective.

Hah. Depends how large the companies are, but again in my experience all that B2B stuff is meaningless. Maybe it's only my company that's terrible at writing, measuring and enforcing service levels, and certainly awful at extracting any penalties (I guess because any downtime doesn't have a direct monetary loss, just a reputation lost which eventually leads to monetary loss)

That said my entire industry (broadcast) relies massively on IT - far more than in the past - and has absolutely no clue about security. In 20 minutes I found 130 of 200 devices on the internet with default credentials open on port 80. Case in point, using shodon, I can find a server and see within seconds that a Polish broadcaster is currently streaming some people playing violins from a studio - not sure if this is a live TV broadcast or being taped for later, it might be going out on "Program 2" on Polskie Radio, but I'm not an expert in the Polish broadcast landscape.

I'm just amazed how anyone could be in a position to have knowledge and authority to change the port SSH is listening on (thus breaking peoples workflows), but not change away from using passwords, even if a bastion and/or ip whilelisting isn't allowed.