[arm-allstar] SSHD attacks

[Doug Theriault]

Couple of notes from my experience managing nodes via SSH which might 
help those who are new to the failed login challenge.

Moving SSHd to a different port# helps however may not fully limit your 
exposure.  I use 5 digit port#'s but am still probed. Your ISP may limit 
/ stop these attacks or minimize them by changing your interface routers 
IP address (DHCP lease frequency); some ISP's are better than others.   
I had less troubles when previous ISP changed my routers IP every couple 
weeks, new one is >30days so I see more probes.  Probes/scans can work 
very slowly so as not to be detected by the ISP; the hacker doesn't 
care, they have lots of time to waste.

Majority of these attacks are BOTs with unique IP addresses that can 
originate any where on the planet.  I've mapped several attacks of 
thousands of unique IP's coming from all over the world on a single 
node.  Attacks can last many weeks and typically stop when your WAN 
address changes.

If you use iptables rules to block large addresses, you may be limiting 
connections from places you want.  I started out doing this for well 
known nefarious countries, large CIDR blocks but was loosing game and 
the iptables rules grew very large very quickly.

BOTs scan your nodes looking for any open ports.  Keep all your ports 
closed unless you need them.  I too use reverse tunnels to manage nodes 
at couple of my mt top sites but you might have better luck using VPN 
circuits instead.   Scanners detect an SSHd server exists on a port and 
is available, then the hacker launches a brute force password 
attacks/scripts to try and get in.

I do not allow username/password for SSH circuits.  I only allow login 
via SSH key.  This is minor config change to your sshd_config to only 
allow login via ssh keys.  Now this won't stop attempts, they still try 
and use username/passwords and will try and throw fake keys at you in an 
attempt to break the sshd server.

I use fail2ban, but also run several monitoring scripts that capture 
data to track the attack and to make sure I don't inadvertently filter 
out a tunnel WAN to a remote site.  I also configure fail2ban so an 
attempted failed login is detected very quickly on first failed login 
attempt.  I configured fail2ban iptables rule to silently DROP vs REJECT 
as found this can help slow the BOT down to a crawl.   The offending IP 
is kept in the ssh jail for several weeks.  I've had iptables rules grow 
to ~1000 IP addresses before they begin to age out.  Couple weeks might 
be excessive and overly large iptables rules may slow things down.

While I use fail2ban and have not experienced degradation of performance 
on my nodes, they are lightly used. Typically do not have > 10 connects 
on them (Allstar and EchoLink).

The nodes I use are all rPI3B+ models.

Here's a node that's been up for couple months now:

    Status for the jail: sshd
    |- Filter
    |  |- Currently failed:    0
    |  |- Total failed:    1756
    |  `- Journal matches:    _SYSTEMD_UNIT=sshd.service + _COMM=sshd
    `- Actions
        |- Currently banned:    569
        |- Total banned:    8896

    Username Attempts: 666 ./bad-users.txt

-dt-

On 1/9/21 9:11 AM, "David McGough via ARM-allstar" wrote:
> I'll post updated info about the hvutmptail filter and how to use it later
> today.
>
>
> On Sat, 9 Jan 2021, Brad Trogdon wrote:
>
>> Thanks for the tip!   A little more digging I did see that that note was a
>> focus.   This one is non standard but somehow got found. :/
>>
>> The filter helper you referenced how can I find info on that puppy?   And
>> what started my looking is all of a sudden all my Reverse SSH connections
>> are failing.  Love the hobby keeps me with things to do and investigate.
>>
>> -Brad
>>
>> On Sat, Jan 9, 2021 at 10:48 AM David McGough <kb4fxc at inttek.net> wrote:
>>
>>> Brad,
>>>
>>> I recommend changing the ssh server to use a non-standard port and then
>>> adding some iptables filtering to limit excessive connections. I wrote a
>>> small filter helper in C (hvutmptail program), which is very lightweight.
>>>
>>> I don't recommend running fail2ban on an RPi system, since fail2ban itself
>>> can be a resource hog.
>>>
>>> 73, David KB4FXC
>>>
>>>
>>> On Sat, 9 Jan 2021, "Brad Trogdon via ARM-allstar" wrote:
>>>
>>>> Howdy all,  Looking through the threads I don't see a direct answer.
>>>>
>>>> I am getting pounded by login attempts and have turned off the port.  My
>>>> question is should I set up fail2ban or Sshguard to discourage open
>>>> hammering?   Is there anything included in the HamVoIP image that I could
>>>> take advantage of?
>>>>
>>>> -Brad W4INT
>>>> _______________________________________________
>>>>
>>>> ARM-allstar mailing list
>>>> ARM-allstar at hamvoip.org
>>>> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>>>>
>>>> Visit the BBB and RPi2/3/4 web page - http://hamvoip.org
>>>>
>>>
> _______________________________________________
>
> ARM-allstar mailing list
> ARM-allstar at hamvoip.org
> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>
> Visit the BBB and RPi2/3/4 web page - http://hamvoip.org

-- 
73,
Doug - NO1D