
Changes sshd port every 30 seconds, using Two Factor Auth to login - vinnyglennon
https://github.com/benjojo/totp-ssh-fluxer
======
taspeotis
Previous discussion:
[https://news.ycombinator.com/item?id=11750003](https://news.ycombinator.com/item?id=11750003)

------
benjojo12
Hi, 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 authenticate SSH with TOTP tokens, but this is not that.

~~~
niccaluim
> _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!

~~~
mancerayder
I just use DenyHosts. A few rattling attempts, and the IP won't be able to
make another auth attempt again.

~~~
niccaluim
It's very very very rarely the same IP.

------
patrickg_zill
I would install it, but there is not the usual "wget [https://](https://) ...
| bash" setup...

------
e40
I don't understand why this is seen as acceptable, yet port knocking is
derided every time it's brought up.

Since installing fwknopd more than a year ago, we have had not a single
attempt at sshd. Not one. We had a lot before, and it was annoying as hell.

~~~
noonespecial
People get their wires crossed about port knocking because it doesn't add much
security when I'm trying to find a way to hack you. It does add something when
I'm trying randomly to find you to hack.

They make the valid criticism of the first case while you argue the second and
somehow the arguments miss in the middle.

~~~
developer2
If you do not have the ability to eavesdrop on the network between my client
and my server, then port knocking is essentially unhackable. Port knocking
only fails when the malicious party can monitor the network traffic. This is a
valid concern, and I would never say that port knocking by itself is all the
security one needs. It does however completely block all regular "outsiders"
from ever being able to even open a connection to sshd.

If I require 5 ports to be hit in sequence, and blacklist IPs that hit unknown
ports, it is extremely unlikely you will ever connect. Now if someone on my
local network, at my ISP, or at my hosting provider sniffs my traffic to
determine a static knocking sequence... good for them. They're the _one_
unauthorized person who can connect to sshd, without a valid ssh key to
authenticate with.

It's a reality that most businesses are not going to invest in setting up a
network that cannot be accessed from the internet at large. For such setups, a
little bit of obscurity via something like port knocking to prevent every
single port scanner in existence from discovering your sshd server must be
better than nothing at all.

~~~
munin
> blacklist IPs that hit unknown ports

so what happens when someone hits an unknown port on your system from every IP
on the internet?

~~~
developer2
You reject all packets from "bad IPs" for a period of time. 5 minutes, 30
minutes, whatever. If you're in a position to spoof IPs and you manage to
spoof one I need to connect from (or I make a mistake and get myself
blacklisted), it's a temporary inconvenience.

That, and having out-of-band access to the server always helps. ;)

------
mschuster91
Nice idea, but tbh I'd prefer if someone rewrote it in (ba)sh scripts. Not
everyone likes to install dozens of different language interpreters/runtimes
on his systems - Ruby for puppet, perl is these days mainly used by apt-get,
Go, NodeJS, some people use PHP, then Java, the Python version hell with
people using either 2.7 or 3.x, Mono, bash, zsh, C, C++...

As much as I like flexibility and "the right tool for the right job", we have
ended with ridiculously huge install bases - a minimal Debian may very well
end up with hundreds of megabytes, it's ridiculous.

Mandatory xkcd: [https://xkcd.com/927/](https://xkcd.com/927/)

~~~
Nullabillity
I dislike Go as well, but it does compile to a static binary, so you shouldn't
need to install any runtime at all.

------
daraosn
Is there a service that wraps/proxies a port with a different or custom
protocol? (kind of like SSL for HTTP)

Idea: instead of ssh'ing a server, you would run your custom command which
communicates to port XXXX, communicate with a custom protocol and then if
validation succeeds, would proxy to SSH (or any other internal port/protocol).

Why? Because as others suggested you could scan all ports very quickly to
break this, but if you scan a port and just receive garbage or something only
you can understand when opening it, then you could hide it from the outside..

(Just curious)

~~~
xg15
Seems possible (though very time-consuming) if you just use it to protect your
hobby/toy machines. As soon as your protocol becomes important enough that it
attracts the attention of human hackers and not just bots they can easily
reverse-engeneer it.

By the way, I think you could view encrypted connections as a sort of
automation of that practice: A crypto algorithm could be seen as a machine
that generates "custom protocols" given a key...

~~~
daraosn
That's a interesting idea, to make encryption dynamic using something like the
2FA described here.

~~~
frutiger
Encryption in most commonly used protocols are dynamic - each session
generates a brand new session key that are negotiated such that only the
holders of the private keys can discern.

------
geocar
This 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?

~~~
brudgers
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 the lower end, this sort of measure probably keeps a wordpress
site in the middle of the herd when wolves invite themselves to dinner.

~~~
gist
> The other says, that's stupid, you'll never out run a grizzly bear.

(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")

------
cperciva
A far more secure approach:
[http://www.daemonology.net/blog/2012-08-30-protecting-
sshd-u...](http://www.daemonology.net/blog/2012-08-30-protecting-sshd-using-
spiped.html)

------
geggam
All of these port knocking folks who talk about logs getting full.... quit
logging the rejected connections.

Log 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 ?

------
Animats
Reminds me of "port knocking", a similar form of security through obscurity.

Still, this stuff is useful just to thin out all the crap coming in from
botnets.

------
dohqu8Zi
So, this is [http://shimmer.sourceforge.net/](http://shimmer.sourceforge.net/)
rewritten in go?

------
cel1ne
I just set the port to something > 10000 and configure it to use public key
authentication only.

~~~
sschueller
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?

~~~
noinsight
They can only do that if the ssh daemon isn't already listening on the port,
i.e. it has crashed or is not running.

------
jftuga
This is also an interesting idea:

[http://serverfault.com/a/217066/46738](http://serverfault.com/a/217066/46738)

(accepted answer is pasted below)

Rate limiting login attempts is an easy way to prevent some of the high speed
password guessing attacks. However, it's hard to limit distributed attacks and
many run at a low pace over weeks or months. I personally prefer to avoid
using automated response tools like fail2ban. And this is for two reasons:

1) Legitimate users sometimes forget their passwords. I don't want to ban
legitimate users from my server, forcing me to manually enable their accounts
again (or worse, try to figure out which of the 100/1000 banned IP addresses
is theirs).

2) An IP address is not a good identifier for a user. If you have multiple
users behind a single IP (for example, a school that runs NAT on 500 student
machines) a single user making a few bad guesses can land you in a world of
pain. At the same time the majority of the password guessing attempts I see
are distributed.

Therefore I don't consider fail2ban (and similar automated response tools) a
very good approach to securing a server against brute force attacks. A simple
IPTables rules set to cut down on the log spam (which I have on most of my
linux servers) is something like this:

    
    
        iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
    
        iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP
    

It prevents more than 4 connection attempts from a single IP to ssh in any 60
second period. The rest can be handled by ensuring passwords are reasonably
strong. On high security servers forcing the users to use public key
authentication is another way to stop guessing.

\---- (end of answer)

for Ubuntu admins...

[http://manpages.ubuntu.com/manpages/xenial/man8/ufw.8.html](http://manpages.ubuntu.com/manpages/xenial/man8/ufw.8.html)

(Uncomplicated Firewall) ufw supports connection rate limiting, which is
useful for protecting against brute-force login attacks. When a limit rule is
used, ufw will normally allow the connection but will deny connections if an
IP address attempts to initiate 6 or more connections within 30 seconds. See
[http://www.debian-administration.org/articles/187](http://www.debian-
administration.org/articles/187) for details.

Typical usage is:

    
    
         ufw limit ssh/tcp

~~~
joelhaasnoot
> On high security servers forcing the users to use public key authentication
> is another way to stop guessing.

Public key and IP limiting is standard practice, eliminating passwords should
be top priority for anyone running SSH servers.

