They are trying to hack me again

[PremierHostingCompan]

Does anyone know how to stop them from attempting to log in using fonie users and passwords, 1000's of them per hour with different IP's. I use the command tail -f -n 50 /var/log/secure | grep sshd to see exactly what they are doing.

Screen Shot 2020-04-15 at 1.31.44 PM.png (81.6 KiB) Viewed 1973 times

I already closed all ports that are not in use.
Added Maldet, RKHunter and Fail2ban - took away ssh directly to root etc

I know he's whistling up the wrong tree, but I would like to stp him in his tracks

Anyones help would be appreciated..

[TrevorH]

Your picture is way to small to be read.

I presume it's just a log file excerpt of skript kiddies trying different ssh logins. The solution is to configure fail2ban to stop that. You installed it but I guess you didn't enable/configure the right bits.

[lightman47]

There is no stopping attempts! That said, TrevorH has sound advice on how to deal with them. I use fail2ban and recommend it, but as mentioned, it needs to be configured after the install. First step (as mentioned at the top of the two .conf files) is to copy them to '.local' files - and then edit those .local files!

Disable root logins in ssh (/etc/ssh/sshd_config).

Code: Select all

    PermitRootLogin no

Don't run as root except for a task or two.

[KernelOops]

fail2ban helps when they re-use the same IP addresses over and over again, you block them once and they go away. But it doesn't help when they switch IP addresses all the time, for example when they try only 3 logins per IP, fail2ban... fails... to ban

while not a real security policy, I've seen amazing results when I randomize my sshd port. For example, come up with a scheme, Monday is port 9000, tuesday is port 8700, whatever you like. Then on the client computer, you create an ~/.ssh/config file that always points to the correct address and a cron job on both server and client to switch to the daily port automatically.

the result? it confuses everyone (including you! ha!) it forces even the most dedicated attacker to re-scan your ports over and over again and cause significant delays. And you'll walk around your own systems and not even notice anything...


truth be told, when I have static IP addresses, I assign ssh access only to those IPs and its end of story for whatever kid wants to brute force their way... (really hard btw, since I don't use passwords, only ed25519 keys) still, static IPs is more serious protection but sometimes not possible.

[lightman47]

fail2ban helps when they re-use the same IP addresses over and over again, you block them once and they go away. But it doesn't help when they switch IP addresses all the time, for example when they try only 3 logins per IP, fail2ban... fails... to ban

Well, yes & no.- when they try another address, that gets banned as well after (retries you stipulate - mine are VERY low). If they try fewer times, then go away for a while -- problem still solved. When they eventually 'come back', my setup "remembers" for a long, long time - then next failure will lock them out (my config locks out ALL ports for an address when a fail occurs on any port).

Settings are VERY configurable. Two tries on mine and you're locked for MONTHS! Also, it isn't only ssh - I'm blocking a lot of http attempts as well as vsftp fails.

[PremierHostingCompan]

Sorry for the small pic, when trying to upload it refused me because of the size..

Like I said root is disabled, you have to log in as a user first different PW then su into root

I don't use port 22 I change it a few times a year, but I noticed that port 22 and my port were running side by side, so I dropped 22 and whalla the connections dropped.

I use file2ban and its been running a few days, I'll look into the config more

Thank you to all who gave here

Mark



Here is a small portion on what [tail -f -n 50 /var/log/secure | grep sshd] will bring you
Apr 15 19:42:24 6aa43ee sshd[28450]: Invalid user guest from 194.87.237.247 port 50904
Apr 15 19:42:24 6aa43ee sshd[28450]: input_userauth_request: invalid user guest [preauth]
Apr 15 19:42:24 6aa43ee sshd[28450]: pam_unix(sshd:auth): check pass; user unknown
Apr 15 19:42:24 6aa43ee sshd[28450]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=194.87.237.247
Apr 15 19:42:24 6aa43ee sshd[28445]: Invalid user www from 124.251.110.164 port 55904
Apr 15 19:42:24 6aa43ee sshd[28445]: input_userauth_request: invalid user www [preauth]
Apr 15 19:42:24 6aa43ee sshd[28445]: pam_unix(sshd:auth): check pass; user unknown
Apr 15 19:42:24 6aa43ee sshd[28445]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=124.251.110.164
Apr 15 19:42:25 6aa43ee sshd[28446]: Failed password for root from 178.128.121.188 port 34450 ssh2
Apr 15 19:42:25 6aa43ee sshd[28446]: Received disconnect from 178.128.121.188 port 34450:11: Bye Bye [preauth]
Apr 15 19:42:25 6aa43ee sshd[28446]: Disconnected from 178.128.121.188 port 34450 [preauth]
Apr 15 19:42:26 6aa43ee sshd[28450]: Failed password for invalid user guest from 194.87.237.247 port 50904 ssh2
Apr 15 19:42:27 6aa43ee sshd[28445]: Failed password for invalid user www from 124.251.110.164 port 55904 ssh2
Apr 15 19:42:27 6aa43ee sshd[28450]: Received disconnect from 194.87.237.247 port 50904:11: Bye Bye [preauth]
Apr 15 19:42:27 6aa43ee sshd[28450]: Disconnected from 194.87.237.247 port 50904 [preauth]

[hunter86_bg]

I use port knocking in order to respond to icmp or allow ssh.

No icmp echo reply - no ssh attempts.

[KernelOops]

Port knocking is another great tool, I've seen similar results to port jumping.

While these tricks are just that... tricks, on their own they don't offer any real protection, remember security through obscurity is no real security. But, these tricks when used as layers on top of other security measures, create an awesome combination!

These tricks are a great defence against a 0-day exploit of sshd