I just set the port to something > 10000 and configure it to use public key authentication only.
Isn't it safer to keep the ssh port below 1024 so that another user other than root can't start a listener on that port?
Changes sshd port every 30 seconds, using Two Factor Auth to login
51–60 of 76 posts
Re: Changes sshd port every 30 seconds, using Two Factor Auth to login
#52Earlier quoted context omitted.
How would that even be possible?
A new change in systemd made it so that nohup'd processes are killed by systemd after you log out.
Re: Changes sshd port every 30 seconds, using Two Factor Auth to login
#53Log the accepted connections.
Reminds me of Butch Cassidy movie where the old man told them they were silly for worrying about getting robbed before they had the money.
If people cant get in they cant do bad things(tm)
BTW... is there an ansible playbook for portnocking with config management ?
Re: Changes sshd port every 30 seconds, using Two Factor Auth to login
#54Re: Changes sshd port every 30 seconds, using Two Factor Auth to login
#55Re: Changes sshd port every 30 seconds, using Two Factor Auth to login
#56This is a very bad idea. If I suspect you're doing this, I can definitely probe 30k ports silently within a second. How many tries do you think I need to break the last two digits?
Two men walking in the woods enter grizzly country. One stops and swaps his hiking boots for running shoes. The other says, that's stupid, you'll never out run a grizzly bear. The technical concerns fall under the category of security. The business concerns fall under risk mitigation. These concerns converge as the value of an enterprise's assets rises. Banks and blogs are toward different ends of the spectrum. At th…
(For those who don't know the punchline of this is "I don't have to outrun the bear I just have to outrun you")
Re: Changes sshd port every 30 seconds, using Two Factor Auth to login
#57Still, this stuff is useful just to thin out all the crap coming in from botnets.
Re: Changes sshd port every 30 seconds, using Two Factor Auth to login
#58Earlier quoted context omitted.
If someone could break 4096 bit ssh keys they could scan every single TCP port on the internet in seconds.
What?
180 seconds is still seconds. Randomizing ports really doesn't buy much.
Re: Changes sshd port every 30 seconds, using Two Factor Auth to login
#59Hi, Author of this here! The title "Changes sshd port every 30 seconds, using Two Factor Auth to login" This isn't what the project is about, It was mainly done as a joke for all of the people who say "Changing your port is security by obscurity", and thus the idea came to make a even more insane/silly version of it. It's using "two factor" to generate the port to connect, not to login, there are loads of ways to aut…
> a joke for all of the people who say "Changing your port is security by obscurity" This always tickled me. I don't do it for security; I do it because (on public-facing servers) it keeps the constant stream of doorknob-rattling out of the logs!
Re: Changes sshd port every 30 seconds, using Two Factor Auth to login
#60Earlier quoted context omitted.
It's weird that you trust randomizing the port over a range of [0, 65536) over the trust you have for the cryptographic strength of a 4096-bit RSA key (or equivalent).
But is it not true that a random port helps specifically against DoS attacks?
- I have some kind of SSH-specific DoS and will simply enumerate ports until I find SSH, which readily identifies itself right off the bat by nature of the protocol. (No config for that.) Result: DoS successful.
- You deploy fail2ban because someone told you to do so because it makes you "safer." Now I can DoS you in three ways since I know (a) there's a Python regex running on your log and (b) naughty addresses will add a netfilter rule, gradually slowing down each packet as it traverses INPUT. What's that, Lassie? A /16 fell down the SSH port while I inundated fail2ban with failures? (Why do you think fail2ban doesn't have IPv6 support yet? I'm just waiting for [0] since solving the problem is intractable, despite what is common consensus in that community. Oh, you're flattening prefixes? How cute. Watch me find the corner cases in your flattening algorithm since I have several googols of v6 addresses to play with.) Result: DoS successful.
- I grow bored of your mildly annoying countermeasures and simply fire up a reflection attack that targets you with several gigabit/sec of traffic behind the aft nacelle, not caring where your SSH lives. Result: Vastly more probable DoS super successful once your hosting provider null routes you. Add cron to watch for your return. Repeat. Follow you to the new IP when you try that because I will invariably find it (probably when you get back on IRC). Walk over your cold server's corpse while you panic and email CloudFlare who can't help, and you can't afford who can. The end.
Now, shall we begin?
There is a lot of shitty shaman wisdom, some making an appearance in this thread, around the SSH port and logging and yadda yadda that actually makes things less safe for a lot of people who don't know better. Most people move SSH from 22 to something like 2200, forgetting that Correct, and only correct, answer: leave sshd on 22 and get your squishy services off the public Internet or rotate the logs faster. You are a sysadmin with grep and awk. Deal with failures in your log. They are there for a reason, especially if you are exposing sshd to the Internet, and pulling netfilter in or moving ports around is silly TSA-level security theater.
This is all promulgated by those "do these ten things first when you install Ubuntu" guides which capitalize on folks not knowing any better to identify (often faulty) opinion. If you followed one lately it's probably steered you wrong, much like those Learn Sushi Preparation in 24 Hours books. Take the time to understand the problem if you're going to operate services on the Internet and get away from guides. (And yes, I am indicting you for writing one, iff yours includes anything discussed in this comment. Sorry.)
Knocking is the only truly plausible, though still silly, security idea here but even that betrays itself in an nmap by nature of TCP. Also, hope you don't forget your knock when your machine is on fire. (You will.)
It's too bad I'm on the right side of ethical these days or I'd patch all the common SSH scanners to try every port so people will stop doing stuff like this. Some already do.