Re: auth log full with
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
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
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
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
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
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
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
Re: auth log full with
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