Increased abuse activity on my server

Valeri Galtsev galtsev at
Wed Mar 7 16:17:49 UTC 2018

On 03/07/18 08:20, William Dudley wrote:
> This may sound stupid and obvious, but I moved my ssh port to a high
> "random" port
> number, and that completely stopped the random attempts to ssh in.  I know
> that
> "security by obscurity" "doesn't work", but it did!

No it doesn't. One mostly fools oneself by seeing less symptoms, whereas 
illness is still as bad as it was (if it was there that is). Sorry, it 
looks like I'm in contradictive mood, still bear with me.

> I picked a port like 5792 -- not related to anything else.  (i.e. don't
> pick 2222 or 2022 etc.)

Do you know why ports for central standard services are chosen in a 
range from 1 to 1023? Just for those who forgot: because on UNIX and 
Linux these ports can be opened by root only. Higher ports do not 
require root privileges to open. Therefore, connecting to higher port 
that asks for your username/password is the same as giving some regular 
user on that machine your credentials. I will stop here, because if 
someone does not realize how bad it is, I hardly can help by continuing.

> I've had this in place for months and months (perhaps a year) and the
> attackers
> haven't found the port yet.
> I think this works because unless you, specifically, are at *target* of
> somebody *serious*,
> (think "kbg"), most of these attackers are opportunists who won't spend the
> time
> to do a full port scan of your server.  They just try the standard ports:
> 21, 22, 23, 25, etc.

If someone as after you, moving port to "non-standard", or hiding 
machine behind some sort of perimeter firewall and using VPN will not 
save you, it will just slow down penetration a bit. Attacker can scan 
ports of your box, and will know on which ports your box is listening. 
VPN usually is used to get on the network where multiple machines are, 
and some of them may be vulnerable to something, which may get one 
bypass step for penetration.

> ALSO, you should disable password auth for ssh and use only public/private
> key.

This is another common misconception, that public key authentication is 
more secure than password based. It is not. Misconception is due to 
disregarding some of the ways of of bad guys getting regular user 
account on the machine. Weak passwords are bad (that is why I usually 
user term "passphrase" when talk to my users). Of course, you can be 
owned from the network on root level if you set root password to 
something which on the very top of the list of crackers dictionary 
attack. One of other ways bad guys get some account is if they 
compromise some machine. Then there are two things they can do: they can 
set up keystroke logger, and get username/password pairs to machines 
people connect to from compromised machine. This takes some time to 
collect. The other thing doesn't take any time: they can just collect 
all ssh key pairs (private/public), and history where each person 
connected. There is protection against this: using secret key protected 
with password (which in my observation people rarely use), then it just 
will take some time to collect these similarly to passwords (keystroke 
logger). One more thing: steal password hashes, and crack them to get 
all accounts on this machine, which is much faster that network based 
brute force attack. This all is if bad guys have root [on compromised 

What one can conclude from the above?

Zero: ssh key pair based authentication is not a panacea, and can be as 
vulnerable as password based one

First: always judge when connecting between two machines which machine 
is more trustworthy than the other, and connect from it to the other 
(not other way around)

Second: never use the same password (or key pair) on different machines. 
(keeypassx is one of the ways to keep many different ones handy and secure)

Third: (this one is for sysadmins, I guess) Run multi user machines in 
an assumption that password of some regular user is stolen and bad guys 
are already inside. Which is: update, update, update... and have one or 
another system integrity watch system so you will know when ultimate bad 
happened (but if you came to this level, after you have done simpler 
things, ultimate bad probably will not happen).

> Then you know the attackers are REALLY wasting their time.

They will, if you just protect from them, not hide symptoms. You can 
user ssghuard of fail2ban. And as you sound like Linux person (judging 
from "hack" way of solution you use - sorry if I am wrong here), you can 
use on Linux in iptables firewall block with --hitcount rule, thus 
dropping connections from those persistent brute force attackers (this 
thing just hangs their script, so you do some bad to them too ;-).

Anyway, I was kind of surprised to read this on FreeBSD mail list, will 
be much less surprised if it were on Linux. I mean here "hack" way of 
solving things which often quite comon for Linux. On the other hand, 
this probably is great news and FreeBSD gets much wider userbase ;-) I 
must mention here, I am myself Linux refugee (not quite recent, and not 
full refugee, as I support big bunch of Linux machines as well).


> Bill Dudley
> This email is free of malware because I run Linux.
> On Wed, Mar 7, 2018 at 4:31 AM, Ole <ole at> wrote:
>> Wed, 7 Mar 2018 08:19:44 +0100 - User Hasse <hasse at>:
>>> Anybody else noticed ?
>> Welcome to the internet :-)
>> If you have strong passwords or better only public key authentication
>> allowed, just don't care. If you want to increase security you could
>> use a VPN + Firewall to only allow connections from your VPN. If you
>> just don't want them to spam your logs you could just move sshd from
>> port 22 to port 24.
>> regards Ole
> _______________________________________________
> freebsd-questions at mailing list
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at"

Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

More information about the freebsd-questions mailing list