Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
Avoiding authentication attempts from the outside
Avoiding authentication attempts from the outside
Hello.
I have debian 10 buster installed.
I am having an issue lately with many many ssh authentication attempts from the outside. At the moment I do not think my computer has been hacked, I hope not, but my auth.log files are full of attempts, incredibly full. Every second or more. And from hundreds of different IPs. I was wondering whether I could insert a delay between failed attempts. I've googled around and not found a way to do it from wothin the sshd_config file. I have read something about it being possible with iptables, but that seems a bit too complex for me.
I must say that the computer still performs well in spite of all these attempts, but I would like to just make it more awkward for whoever is trying to get in.
Any suggestions would be of great help.
Thank you.
I have debian 10 buster installed.
I am having an issue lately with many many ssh authentication attempts from the outside. At the moment I do not think my computer has been hacked, I hope not, but my auth.log files are full of attempts, incredibly full. Every second or more. And from hundreds of different IPs. I was wondering whether I could insert a delay between failed attempts. I've googled around and not found a way to do it from wothin the sshd_config file. I have read something about it being possible with iptables, but that seems a bit too complex for me.
I must say that the computer still performs well in spite of all these attempts, but I would like to just make it more awkward for whoever is trying to get in.
Any suggestions would be of great help.
Thank you.
Last edited by eddie3000 on 2020-06-26 15:43, edited 1 time in total.
Re: Avoiding authentication attempts from the outside
Package fail2ban could be answer you are seeking.
Re: Avoiding authentication attempts from the outside
Thanks. Looked it up and came across this tutorial.
https://upcloud.com/community/tutorials ... an-debian/
It seems easy. I'm going to give it a go and see if I don't break anything.
I have another question. My computer sits behind a router with one port forwarded to the ip address of my computer for ssh. Why do the login attempts in auth.log seem to be coming in on any port except the one configured in sshd_config?
https://upcloud.com/community/tutorials ... an-debian/
It seems easy. I'm going to give it a go and see if I don't break anything.
I have another question. My computer sits behind a router with one port forwarded to the ip address of my computer for ssh. Why do the login attempts in auth.log seem to be coming in on any port except the one configured in sshd_config?
Re: Avoiding authentication attempts from the outside
Done! Now I'll just have to wait and see if it works.
Thanks.
Thanks.
Re: Avoiding authentication attempts from the outside
After a few days I've just noticed that fail2ban is not working. The login attempts have stopped too, but that's just a coincidence. I have tried doing failing logins myself on purpose and they don't get banned, but do appear in auth.log
I just copied fail2ban.conf to fail2ban.local as many tutorials suggest.
The fail2ban.log file does not get created either.
And sudo iptables -L returns this.
I have read various tutorials and according to them fail2ban should work as soon as it's installed. And I have also read that debain 10 has some issues with fail2ban. Is this true?
What could I do to get it working?
Thanks.
Code: Select all
eddie@rtve:~$ sudo fail2ban-client status
[sudo] password for eddie:
Failed to access socket path: /var/run/fail2ban/fail2ban.sock. Is fail2ban running?
Code: Select all
logtarget = /var/log/fail2ban.log
socket = /var/run/fail2ban/fail2ban.sock
And sudo iptables -L returns this.
Code: Select all
eddie@rtve:~$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
What could I do to get it working?
Thanks.
Re: Avoiding authentication attempts from the outside
I think I got it working, but time will tell.
I tried starting fail2ban manually with:
It produced an error pointing to line 24 in /etc/fail2ban/jail.local which was:
I commented out the enabled = true. And restarted manually the service like before. Now it seems to be working. The log file /var/log/fail2ban.log has been created and has some content.
Now I also get some feedback from fail2ban different from before.
I'll reboot and see if it still works and let it sit for some time hoping somebot might try logging into my machine, hopefully without success!
But it's a mystery to me why I have to comment that line out. It seems ssh is on by default on fail2ban on debian, telling it specifically to enable sshd shouldn't produce an error. But I must be mistaken, surely.
I tried starting fail2ban manually with:
Code: Select all
sudo fail2ban-client -vvv start
Code: Select all
# [sshd]
enabled = true
#
Now I also get some feedback from fail2ban different from before.
Code: Select all
sudo fail2ban-client status
Status
|- Number of jail: 1
`- Jail list: sshd
But it's a mystery to me why I have to comment that line out. It seems ssh is on by default on fail2ban on debian, telling it specifically to enable sshd shouldn't produce an error. But I must be mistaken, surely.
Re: Avoiding authentication attempts from the outside
Even though this forum is pretty quiet, here I am making up for the calm silence.
Just came to my mind that fail2ban would not be able to ban the type of attack I am recieving. Here's a fraction of my 15MB auth.log file of about two weeks ago:
If the attacker changes ip with every attempt, fail2ban cannot ban a specific ip address. So, even though I have fail2ban up and running, it's no good here.
But it would have worked here:
One more question. How can I know if the computer has been compromised?
Just came to my mind that fail2ban would not be able to ban the type of attack I am recieving. Here's a fraction of my 15MB auth.log file of about two weeks ago:
Code: Select all
Jun 16 12:27:24 debian sshd[7681]: Disconnected from invalid user jboss 106.12.3.28 port 49040 [preauth]
Jun 16 12:27:29 debian sshd[7683]: Invalid user provider from 182.76.255.214 port 41542
Jun 16 12:27:29 debian sshd[7683]: Received disconnect from 182.76.255.214 port 41542:11: Normal Shutdown, Thank you for playing [preauth]
Jun 16 12:27:29 debian sshd[7683]: Disconnected from invalid user provider 182.76.255.214 port 41542 [preauth]
Jun 16 12:27:30 debian sshd[7685]: Invalid user ts3 from 159.65.54.221 port 38018
Jun 16 12:27:30 debian sshd[7685]: Received disconnect from 159.65.54.221 port 38018:11: Normal Shutdown, Thank you for playing [preauth]
Jun 16 12:27:30 debian sshd[7685]: Disconnected from invalid user ts3 159.65.54.221 port 38018 [preauth]
Jun 16 12:27:36 debian sshd[7687]: Received disconnect from 144.76.11.195 port 57949:11: Normal Shutdown, Thank you for playing [preauth]
Jun 16 12:27:36 debian sshd[7687]: Disconnected from authenticating user root 144.76.11.195 port 57949 [preauth]
Jun 16 12:27:37 debian sshd[7689]: Invalid user zhuang from 39.105.200.55 port 52980
Jun 16 12:27:37 debian sshd[7689]: Received disconnect from 39.105.200.55 port 52980:11: Normal Shutdown, Thank you for playing [preauth]
Jun 16 12:27:37 debian sshd[7689]: Disconnected from invalid user zhuang 39.105.200.55 port 52980 [preauth]
Jun 16 12:27:48 debian sshd[7691]: Received disconnect from 47.107.80.229 port 1257:11: Normal Shutdown, Thank you for playing [preauth]
Jun 16 12:27:48 debian sshd[7691]: Disconnected from authenticating user uucp 47.107.80.229 port 1257 [preauth]
Jun 16 12:27:59 debian sshd[7697]: Invalid user min from 139.59.180.53 port 32828
Jun 16 12:27:59 debian sshd[7697]: Received disconnect from 139.59.180.53 port 32828:11: Normal Shutdown, Thank you for playing [preauth]
Jun 16 12:27:59 debian sshd[7697]: Disconnected from invalid user min 139.59.180.53 port 32828 [preauth]
Jun 16 12:28:00 debian sshd[7693]: Invalid user git from 47.105.164.105 port 59818
Jun 16 12:28:00 debian sshd[7695]: Invalid user admin from 47.96.144.102 port 49706
Jun 16 12:28:01 debian sshd[7693]: Received disconnect from 47.105.164.105 port 59818:11: Normal Shutdown, Thank you for playing [preauth]
Jun 16 12:28:01 debian sshd[7693]: Disconnected from invalid user git 47.105.164.105 port 59818 [preauth]
Jun 16 12:28:01 debian sshd[7695]: Received disconnect from 47.96.144.102 port 49706:11: Normal Shutdown, Thank you for playing [preauth]
Jun 16 12:28:01 debian sshd[7695]: Disconnected from invalid user admin 47.96.144.102 port 49706 [preauth]
Jun 16 12:28:03 debian sshd[7699]: Invalid user calvin from 60.12.26.9 port 47157
Jun 16 12:28:03 debian sshd[7699]: Received disconnect from 60.12.26.9 port 47157:11: Normal Shutdown, Thank you for playing [preauth]
Jun 16 12:28:03 debian sshd[7699]: Disconnected from invalid user calvin 60.12.26.9 port 47157 [preauth]
Jun 16 12:28:12 debian sshd[7701]: Invalid user igf from 139.59.61.6 port 48470
Jun 16 12:28:12 debian sshd[7701]: Received disconnect from 139.59.61.6 port 48470:11: Normal Shutdown, Thank you for playing [preauth]
Jun 16 12:28:12 debian sshd[7701]: Disconnected from invalid user igf 139.59.61.6 port 48470 [preauth]
Jun 16 12:28:26 debian sshd[7703]: Invalid user alias from 188.166.191.192 port 51556
Jun 16 12:28:26 debian sshd[7703]: Received disconnect from 188.166.191.192 port 51556:11: Normal Shutdown, Thank you for playing [preauth]
Jun 16 12:28:26 debian sshd[7703]: Disconnected from invalid user alias 188.166.191.192 port 51556 [preauth]
Jun 16 12:28:28 debian sshd[7705]: Invalid user john from 159.65.136.194 port 56468
Jun 16 12:28:28 debian sshd[7705]: Received disconnect from 159.65.136.194 port 56468:11: Normal Shutdown, Thank you for playing [preauth]
Jun 16 12:28:28 debian sshd[7705]: Disconnected from invalid user john 159.65.136.194 port 56468 [preauth]
Jun 16 12:28:32 debian sshd[7707]: Invalid user dummy from 39.107.91.81 port 52316
Jun 16 12:28:32 debian sshd[7707]: Received disconnect from 39.107.91.81 port 52316:11: Normal Shutdown, Thank you for playing [preauth]
Jun 16 12:28:32 debian sshd[7707]: Disconnected from invalid user dummy 39.107.91.81 port 52316 [preauth]
Jun 16 12:28:36 debian sshd[7709]: Invalid user zhu from 211.253.9.160 port 52232
Jun 16 12:28:36 debian sshd[7709]: Received disconnect from 211.253.9.160 port 52232:11: Normal Shutdown, Thank you for playing [preauth]
Jun 16 12:28:36 debian sshd[7709]: Disconnected from invalid user zhu 211.253.9.160 port 52232 [preauth]
Jun 16 12:28:38 debian sshd[7711]: Invalid user giter from 58.16.136.126 port 54195
Jun 16 12:28:39 debian sshd[7711]: Received disconnect from 58.16.136.126 port 54195:11: Normal Shutdown, Thank you for playing [preauth]
Jun 16 12:28:39 debian sshd[7711]: Disconnected from invalid user giter 58.16.136.126 port 54195 [preauth]
Jun 16 12:28:42 debian sshd[7715]: Invalid user phion from 181.189.222.130 port 38599
Jun 16 12:28:42 debian sshd[7715]: Received disconnect from 181.189.222.130 port 38599:11: Normal Shutdown, Thank you for playing [preauth]
Jun 16 12:28:42 debian sshd[7715]: Disconnected from invalid user phion 181.189.222.130 port 38599 [preauth]
Jun 16 12:28:43 debian sshd[7713]: Invalid user jack from 115.29.143.215 port 58318
Jun 16 12:28:44 debian sshd[7713]: Received disconnect from 115.29.143.215 port 58318:11: Normal Shutdown, Thank you for playing [preauth]
Jun 16 12:28:44 debian sshd[7713]: Disconnected from invalid user jack 115.29.143.215 port 58318 [preauth]
But it would have worked here:
Code: Select all
Jun 20 19:30:01 debian CRON[9526]: pam_unix(cron:session): session closed for user root
Jun 20 19:32:36 debian sshd[9530]: Invalid user user from 202.98.194.122 port 6664
Jun 20 19:32:37 debian sshd[9530]: Connection closed by invalid user user 202.98.194.122 port 6664 [preauth]
Jun 20 19:43:16 debian sshd[9534]: Invalid user user from 202.98.194.122 port 6664
Jun 20 19:43:16 debian sshd[9534]: Connection closed by invalid user user 202.98.194.122 port 6664 [preauth]
Jun 20 19:53:27 debian sshd[9538]: Invalid user user from 202.98.194.122 port 6664
Jun 20 19:53:27 debian sshd[9538]: Connection closed by invalid user user 202.98.194.122 port 6664 [preauth]
Jun 20 20:03:17 debian sshd[9541]: Invalid user test from 202.98.194.122 port 6664
Jun 20 20:03:18 debian sshd[9541]: Connection closed by invalid user test 202.98.194.122 port 6664 [preauth]
Jun 20 20:12:50 debian sshd[9544]: Invalid user test from 202.98.194.122 port 6664
Jun 20 20:12:51 debian sshd[9544]: Connection closed by invalid user test 202.98.194.122 port 6664 [preauth]
Jun 20 20:17:01 debian CRON[9547]: pam_unix(cron:session): session opened for user root by (uid=0)
Jun 20 20:17:01 debian CRON[9547]: pam_unix(cron:session): session closed for user root
Jun 20 20:22:11 debian sshd[9550]: Invalid user test from 202.98.194.122 port 6664
Jun 20 20:22:12 debian sshd[9550]: Connection closed by invalid user test 202.98.194.122 port 6664 [preauth]
Jun 20 20:30:01 debian CRON[9553]: pam_unix(cron:session): session opened for user root by (uid=0)
Jun 20 20:30:01 debian CRON[9553]: pam_unix(cron:session): session closed for user root
Jun 20 20:31:23 debian sshd[9557]: Connection closed by authenticating user root 202.98.194.122 port 6664 [preauth]
Jun 20 20:40:27 debian sshd[9561]: Invalid user mqm from 202.98.194.122 port 6664
Jun 20 20:40:28 debian sshd[9561]: Connection closed by invalid user mqm 202.98.194.122 port 6664 [preauth]
Jun 20 20:49:27 debian sshd[9564]: Invalid user mqm from 202.98.194.122 port 6664
Jun 20 20:49:28 debian sshd[9564]: Connection closed by invalid user mqm 202.98.194.122 port 6664 [preauth]
Jun 20 20:58:19 debian sshd[9567]: Connection closed by authenticating user root 202.98.194.122 port 6664 [preauth]
Jun 20 21:07:06 debian sshd[9570]: Invalid user john from 202.98.194.122 port 6664
Jun 20 21:07:07 debian sshd[9570]: Connection closed by invalid user john 202.98.194.122 port 6664 [preauth]
Jun 20 21:15:50 debian sshd[9573]: Connection closed by authenticating user root 202.98.194.122 port 6664 [preauth]
Jun 20 21:17:01 debian CRON[9575]: pam_unix(cron:session): session opened for user root by (uid=0)
Jun 20 21:17:01 debian CRON[9575]: pam_unix(cron:session): session closed for user root
Jun 20 21:24:25 debian sshd[9578]: Invalid user 0racle from 202.98.194.122 port 6664
Jun 20 21:24:25 debian sshd[9578]: Connection closed by invalid user 0racle 202.98.194.122 port 6664 [preauth]
Jun 20 21:30:01 debian CRON[9581]: pam_unix(cron:session): session opened for user root by (uid=0)
Jun 20 21:30:01 debian CRON[9581]: pam_unix(cron:session): session closed for user root
Jun 20 21:33:04 debian sshd[9585]: Invalid user 0racle from 202.98.194.122 port 6664
Jun 20 21:33:05 debian sshd[9585]: Connection closed by invalid user 0racle 202.98.194.122 port 6664 [preauth]
Jun 20 21:41:44 debian sshd[9589]: Invalid user oracle from 202.98.194.122 port 6664
Jun 20 21:41:44 debian sshd[9589]: Connection closed by invalid user oracle 202.98.194.122 port 6664 [preauth]
Jun 20 21:50:14 debian sshd[9592]: Invalid user oracle from 202.98.194.122 port 6664
Jun 20 21:50:14 debian sshd[9592]: Connection closed by invalid user oracle 202.98.194.122 port 6664 [preauth]
Jun 20 21:58:48 debian sshd[9595]: Invalid user oracle from 202.98.194.122 port 6664
Jun 20 21:58:48 debian sshd[9595]: Connection closed by invalid user oracle 202.98.194.122 port 6664 [preauth]
Jun 20 22:07:17 debian sshd[9598]: Invalid user oracle from 202.98.194.122 port 6664
Jun 20 22:07:18 debian sshd[9598]: Connection closed by invalid user oracle 202.98.194.122 port 6664 [preauth]
Jun 20 22:15:43 debian sshd[9601]: Invalid user oracle from 202.98.194.122 port 6664
Jun 20 22:15:43 debian sshd[9601]: Connection closed by invalid user oracle 202.98.194.122 port 6664 [preauth]
Jun 20 22:17:01 debian CRON[9603]: pam_unix(cron:session): session opened for user root by (uid=0)
Jun 20 22:17:01 debian CRON[9603]: pam_unix(cron:session): session closed for user root
Jun 20 22:24:12 debian sshd[9606]: Invalid user oracle from 202.98.194.122 port 6664
Jun 20 22:24:12 debian sshd[9606]: Connection closed by invalid user oracle 202.98.194.122 port 6664 [preauth]
Jun 20 22:30:01 debian CRON[9609]: pam_unix(cron:session): session opened for user root by (uid=0)
Jun 20 22:30:01 debian CRON[9609]: pam_unix(cron:session): session closed for user root
Jun 20 22:32:39 debian sshd[9611]: Invalid user oracle from 202.98.194.122 port 6664
Last edited by eddie3000 on 2020-07-01 15:07, edited 1 time in total.
Re: Avoiding authentication attempts from the outside
Thank you for posting your progress. I for one, appreciate you detailing the information for us!
Re: Avoiding authentication attempts from the outside
Then you should change tactics. I would leave fail2ban running, as you said it blocked some addresses. Maybe allow only some ip*s, block all the other.eddie3000 wrote:
If the attacker changes ip with every attempt, fail2ban cannot ban a specific ip address. So, even though I have fail2ban up and running, it's no good here.
-
- Posts: 932
- Joined: 2020-05-03 14:16
- Has thanked: 7 times
- Been thanked: 65 times
Re: Avoiding authentication attempts from the outside
This can be very easy or extremely hard, depending on the type of attack.eddie3000 wrote:How can I know if the computer has been compromised?
The rkhunter is a good starting point (it's reasonable to run it from time to time, even if nothing suspicious is happening)
Here is simple overview of what You can do:
https://bash-prompt.net/guides/server-hacked/
https://community.spiceworks.com/how_to ... -been-hack
But the best way is to prevent such situations: search for "Linux server hardening"
Bill Gates: "(...) In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating system."
The_full_story and Nothing_have_changed
The_full_story and Nothing_have_changed
Re: Avoiding authentication attempts from the outside
Thank you very much guys. Absolutely fantastic information.
Rkhunter looks like a great application. I have run it and got a few warnings. Four binaries, /usr/bin/egrep, /usr/bin/fgrep, /usr/bin/which, /usr/bin/ldd turned out all to be false positives. Interestingly, I compared these results with an ubuntu 20.04 machine, and the same files did not get this warning. I opened all the files to compare the contents and they looked identical, so I don't know why the debian 10 ones got a warning (different version maybe). A fresh debian 10 install on a virtual machine also returned the same results. So I guess it's all ok.
I got another rkhunter warning regarding ssh root login, but that was because rkhunter doesn't like the "PermitRootLogin prohibit-password" option in sshd_config. It prefers it set to "no" instead.
And apart from other warnings that seem "typically normal" like hidden files existing on my system, and another point or two that need googling, I guess it's all fine.
The two links provided by LE_746F6D617A7A69 are a must have information for a newbie like myself. After reading them carefully and checking, everything seems OK
The best advice though is, if you suspect your computer is compromised, at the very end of one of the links: "The only sensible course of action is to copy off all the data that you need and start again from a fresh install."
Regarding the distributed brute force attack, yes, I suppose I would have to get all those IPs from the auth.log file and ban them. Not manually, I'd have to come up with a script of some sort to do so. That'll be next on my list.
Today has been a very educative day for me. I appreciate everybody's help.
Rkhunter looks like a great application. I have run it and got a few warnings. Four binaries, /usr/bin/egrep, /usr/bin/fgrep, /usr/bin/which, /usr/bin/ldd turned out all to be false positives. Interestingly, I compared these results with an ubuntu 20.04 machine, and the same files did not get this warning. I opened all the files to compare the contents and they looked identical, so I don't know why the debian 10 ones got a warning (different version maybe). A fresh debian 10 install on a virtual machine also returned the same results. So I guess it's all ok.
I got another rkhunter warning regarding ssh root login, but that was because rkhunter doesn't like the "PermitRootLogin prohibit-password" option in sshd_config. It prefers it set to "no" instead.
And apart from other warnings that seem "typically normal" like hidden files existing on my system, and another point or two that need googling, I guess it's all fine.
The two links provided by LE_746F6D617A7A69 are a must have information for a newbie like myself. After reading them carefully and checking, everything seems OK
The best advice though is, if you suspect your computer is compromised, at the very end of one of the links: "The only sensible course of action is to copy off all the data that you need and start again from a fresh install."
Regarding the distributed brute force attack, yes, I suppose I would have to get all those IPs from the auth.log file and ban them. Not manually, I'd have to come up with a script of some sort to do so. That'll be next on my list.
Today has been a very educative day for me. I appreciate everybody's help.
Re: Avoiding authentication attempts from the outside
I've finally decided not to use fail2ban, and just have strong passwords and strange user names.
- Head_on_a_Stick
- Posts: 14114
- Joined: 2014-06-01 17:46
- Location: London, England
- Has thanked: 81 times
- Been thanked: 132 times
Re: Avoiding authentication attempts from the outside
https://packages.debian.org/buster/tripwireeddie3000 wrote:How can I know if the computer has been compromised?
deadbang
Re: Avoiding authentication attempts from the outside
Tripwire. That looks nice. I suppose it's only good on system installation though. So I would have to re-install my system strating from zero. I will give it a go after reading about it and when I have enough time.
Thank you very much.
Thank you very much.