Re: auth log full with

[Matthias Böttcher]

Am So., 14. Aug. 2022 um 16:42 Uhr schrieb Reco :

> whois, geoiplookup, even https://bgp.he.net .
> Whatever works, basically.
> Last one is my favorite as it shows all IP blocks assigned to AS.
> Really helpful with spammer nests such as outlook.com (AS8075) or
> DigitalOcean (AS14061).
>
> > Is there a Debian packet?
>
> For the first two - sure.
> You'll need whois and geoip-bin. Installing iptables is assumed.

Thanks for your reply, it bumps me in the right direction.

  Matthias

Re: auth log full with

[Lee]

On 8/14/22, Matthias Böttcher wrote:
> Am So., 14. Aug. 2022 um 09:51 Uhr schrieb Reco :
>
>> Personally I don't use fail2ban for sshd. Because why bother with
>> userspace (written in python too, yuck) if the kernel does the same job?
>> I.e. block M$ AS, China Telecom AS and maybe add Eastern Europe to the
>> mix, and you've just reduced the number of offending logins by two
>> orders of magnitude.
>
> Hi Reco,
>
> how do I block these ip ranges?
> Which source can I use to determine the geo location of ip addresses?

I'd suggest a white-list approach - ie. allow ssh from 
networks instead of playing wack-a-mole, but if you _really_ want to
block by country

1. learn expect

2. figure out how to script this bit:

get a list of ASNs (Autonomous System Number) for that country - eg
  https://ipinfo.io/countries/cn

find some route servers that give you telnet access - eg.
  https://bgp4.as/looking-glasses
you want the
  CATEGORY 2 - IPv4 AND IPv6 BGP ROUTE SERVERS BY REGION (TELNET ACCESS)
table at the end of the page

figure out the correct syntax for showing bgp routes transiting the target ASN
for cisco routers it's  "sh ip bgp regexp _ASN#_" so show all routes
transiting that ASN

route-server.he.net  seems to be a cisco router, so
$ telnet route-server.he.net
  ...
route-server> sh ip bgp regexp _4812_
BGP table version is 0, local router ID is 64.62.142.154
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
  i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network  Next HopMetric LocPrf Weight Path
* i36.111.0.0/2064.62.244.62 0100  0 4134 4134 4812 i
*>i 118.85.205.25 100  0 4134 4812 i
* i 118.85.205.25 100  0 4134 4812 i
* i 216.218.252.178  0100  0 4134 4134 4812 i
* i 216.218.252.164  0100  0 4134 4134 4812 i
* i 209.51.191.134   0100  0 4134 4134 4812 i
* i 209.51.191.134   0100  0 4134 4134 4812 i
* i 118.85.205.25 100  0 4134 4812 i
* i 209.51.191.134   0100  0 4134 4134 4812 i
* i 209.51.191.134   0100  0 4134 4134 4812 i
* i 64.62.244.62 0100  0 4134 4134 4812 i
* i 64.62.151.1020100  0 4134 4134 4812 i
* i 64.62.244.62 0100  0 4134 4134 4812 i
* i 209.51.191.134   0100  0 4134 4134 4812 i
* i 209.51.191.134   0100  0 4134 4134 4812 i
* i 216.218.252.169  0100  0 4134 4134 4812 i
* i36.255.128.0/22  118.85.205.25 100  0 4134 4812 63570 i
* i 118.85.205.25 100  0 4134 4812 63570 i
*>i 118.85.205.25 100  0 4134 4812 63570 i
* i40.0.176.0/2162.115.181.197  48 70  0 1299 4134
4812 4249 i
* i 62.115.14.5 48 70  0 1299 4134
4812 4249 i

And don't forget to block ipv6, so
route-server> sh bgp ipv6 regexp _4812_
BGP table version is 0, local router ID is 64.62.142.154
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
  i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network  Next HopMetric LocPrf Weight Path
* i2400:6600::/32   2a04:f580:8210:100::9
 0100  0 4134 4812 9812 i
* i 2001:470:0:38e::2
 0100  0 4134 4812 9812 i
* i 2001:470:0:38e::2
 0100  0 4134 4812 9812 i
* i 2001:470:0:5f::2
 0100  0 4134 4812 9812 i
* i 2001:470:0:1a::1
 0100  0 4134 4812 9812 i
* i 2001:470:0:5f::2
 0100  0 4134 4812 9812 i
* i 2001:470:0:5f::2
 0100  0 4134 4812 9812 i

Regards,
Lee

Re: auth log full with

[Joe]

On Sun, 14 Aug 2022 16:07:03 +0200
Matthias Böttcher  wrote:

> Am So., 14. Aug. 2022 um 09:51 Uhr schrieb Reco
> :
> 
> > Personally I don't use fail2ban for sshd. Because why bother with
> > userspace (written in python too, yuck) if the kernel does the same
> > job? I.e. block M$ AS, China Telecom AS and maybe add Eastern
> > Europe to the mix, and you've just reduced the number of offending
> > logins by two orders of magnitude.  
> 
> Hi Reco,
> 
> how do I block these ip ranges?
> Which source can I use to determine the geo location of ip addresses?

https://geotargetly.com/ip-geolocation-databases

> Is there a Debian packet?
> 

Synaptic turns up 'location'. I've never used it, so I know nothing
about it.

Banning countries by IP address was a non-starter ten years ago. You
wouldn't believe how fragmented the address space has become, as CIDR
blocks originally allocated to one country are found to be under-used
and parts get allocated to other countries.

If your only concern is cleaner logs, then run your ssh server on a
different port. I've done that for over twenty years and have no
problems with clogged logs or bots trying brute-force password attacks.
I'm on keys, anyway. Most Internet routers can let in packets bound for
any port, and rewrite them as going to port 22 on the ssh server.
Alternatively, sshd can use any port.

Disclaimer: I'm well aware that this strategy *provides* *no*
*additional* *security*, but it seems to discourage break-in attempts.
I don't expect it to keep the CIA out. This disclaimer was added for
the benefit of... well, you know who you are.

-- 
Joe

Re: auth log full with

[Reco]

Hi.

On Sun, Aug 14, 2022 at 04:07:03PM +0200, Matthias Böttcher wrote:
> how do I block these ip ranges?

The usual way.

iptables -I INPUT -s  -p tcp --dport 22 \
-m conntrack --ctstate NEW -j DROP

or, if the source IP is an actual IPv6 (a rare thing in my experience):

ip6tables -I INPUT -s  -p tcp --dport 22 \
-m conntrack --ctstate NEW -j DROP

Add your favorite way to persist these between host reboots, and you're
set.

> Which source can I use to determine the geo location of ip addresses?

whois, geoiplookup, even https://bgp.he.net .
Whatever works, basically.
Last one is my favorite as it shows all IP blocks assigned to AS.
Really helpful with spammer nests such as outlook.com (AS8075) or
DigitalOcean (AS14061).

> Is there a Debian packet?

For the first two - sure.
You'll need whois and geoip-bin. Installing iptables is assumed.

Reco

Re: auth log full with

[Matthias Böttcher]

Am So., 14. Aug. 2022 um 09:51 Uhr schrieb Reco :

> Personally I don't use fail2ban for sshd. Because why bother with
> userspace (written in python too, yuck) if the kernel does the same job?
> I.e. block M$ AS, China Telecom AS and maybe add Eastern Europe to the
> mix, and you've just reduced the number of offending logins by two
> orders of magnitude.

Hi Reco,

how do I block these ip ranges?
Which source can I use to determine the geo location of ip addresses?
Is there a Debian packet?

Thanks for your help.

Matthias

Re: auth log full with

[Reco]

Hi.

On Sun, Aug 14, 2022 at 09:16:25AM -0400, Stefan Monnier wrote:
> > In fact, I'd restrict allowed SSH algorithms like this:
> >
> > Ciphers   chacha20-poly1...@openssh.com,aes256-...@openssh.com
> > MACs 
> > hmac-sha2-512-...@openssh.com,hmac-sha2-256-...@openssh.com,umac-128-...@openssh.com
> > KexAlgorithms 
> > curve25519-sha...@libssh.org,diffie-hellman-group-exchange-sha256
> 
> Of course, if you do that, you'll want to make sure to revisit these
> lists every couple of years :-(

That goes without saying. Executing 'ssh -Q chiper' now and then is a
good habit to have.

Reco

Re: auth log full with

[Reco]

Hi.

On Sun, Aug 14, 2022 at 08:57:47AM +0200, Maurizio Caloro wrote:
> Thanks for you answer, yes add aggressive to mode, restart services and add
> to ssh_config
> 
> Host *
> HostKeyAlgorithms +ssh-rsa,ssh-dss
> PubkeyAcceptedKeyTypes +ssh-rsa,ssh-dss

Please do not do this unless you're in a corporate environment.
Basically you just allowed every SSH client made in last 25 years to
connect to you. A very bad idea, to say the least.
In fact, I'd restrict allowed SSH algorithms like this:

Ciphers   chacha20-poly1...@openssh.com,aes256-...@openssh.com
MACs 
hmac-sha2-512-...@openssh.com,hmac-sha2-256-...@openssh.com,umac-128-...@openssh.com
KexAlgorithms curve25519-sha...@libssh.org,diffie-hellman-group-exchange-sha256


Because it does not affect in any way proper OpenSSH users, and you'll
probably want all those annoying bots to fail to connect.
Windows users will suffer, but that's their fate anyway :)

> But still auth logs everysecond with:
> 
> Aug 14 08:53:20 lenovo sshd[270588]: Unable to negotiate with 80.92.231.239
> port 38675: no matching host key type found. Their offer:
> ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ecdsa-sha2-nistp
> 256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2
> -nistp521-cert-...@openssh.com,ssh-rsa,ssh-dss [preauth]

And that shows us that either fail2ban is not suitable for such messages
(which is strange, fail2ban's sshd.conf contains appopriate regexes), or
maybe you did not restart fail2ban.

Personally I don't use fail2ban for sshd. Because why bother with
userspace (written in python too, yuck) if the kernel does the same job?
I.e. block M$ AS, China Telecom AS and maybe add Eastern Europe to the
mix, and you've just reduced the number of offending logins by two
orders of magnitude.

Reco

AW: auth log full with

[Maurizio Caloro]

On Sat, Aug 13, 2022 at 07:42:28PM +0200, Maurizio Caloro wrote:

>As /etc/fail2ban/filter.d/sshd.conf shows, "no matching host key type"
>messages are specifically ignored by Mode=normal.
>Try setting Mode=aggressive, it should catch those.
>
>Of course, DROPping ssh connections from AS28594 would work too. Unless
you're from Brazil, that is.
>
>Reco

Thanks for you answer, yes add aggressive to mode, restart services and add
to ssh_config

Host *
HostKeyAlgorithms +ssh-rsa,ssh-dss
PubkeyAcceptedKeyTypes +ssh-rsa,ssh-dss


But still auth logs everysecond with:

Aug 14 08:53:20 lenovo sshd[270588]: Unable to negotiate with 80.92.231.239
port 38675: no matching host key type found. Their offer:
ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ecdsa-sha2-nistp
256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2
-nistp521-cert-...@openssh.com,ssh-rsa,ssh-dss [preauth]

Thanks
Mauri

Re: auth log full with

[Reco]

Hi.

On Sat, Aug 13, 2022 at 07:42:28PM +0200, Maurizio Caloro wrote:
> how I can disable this?, I try solution with failban, but this want be
> help!?
> 
> [sshd]
> Enable  = true
> Mode   = normal

As /etc/fail2ban/filter.d/sshd.conf shows, "no matching host key type"
messages are specifically ignored by Mode=normal.
Try setting Mode=aggressive, it should catch those.

Of course, DROPping ssh connections from AS28594 would work too. Unless
you're from Brazil, that is.

Reco

auth log full with

[Maurizio Caloro]

 

every 2-3 second this log will by appair inside auth log, and i cant place
this correctly from where this come?

 

Aug 13 19:25:26 Cruscotto sshd[257257]: Unable to negotiate with
200.218.251.153 port 34480: no matching host key type found. Their offer:

ecdsa-sha2-nistp256,ecdsa-sha2->nistp384,ecdsa-sha2-nistp521,ecdsa-sha2-nist
p256-cert-...@openssh.com,

ecdsa-sha2-nistp384-cert-...@openssh.com
 ,
ecdsa-sha2-nistp521-cert-...@openssh.com,ssh-rsa,ssh->dss [preauth]

 

how I can disable this?, I try solution with failban, but this want be
help!?

[sshd]

Enable  = true

Mode   = normal

Port   = ssh

Filter = sshd

Logpath = %(sshd_log)s

Backend = %(sshd_backend)s

 

Thanks