0

My system log file (/var/log/auth.log) is showing hundreds and hundreds of different IP's trying to log into my system. How can I prevent all these attacks? It looks like all the IP addresses are fake ("pin" or "traceroute") always shows hundreds of different IP address in the auth.log file??

I really need help with this! Thanks!

I'm reading that other people suggest

  • StrictModes yes (what does this do?)
  • hosts.allow ALL : (would this allow me to connect if the IP address is from a cafe and its "me me"?)

Here is what my firewall "iptables" looks like..

asher@starparty:~$ 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

I'm reading that other people recommend...

  • iptables -I INPUT -s -p tcp -m tcp --dport 22 -j ACCEPT

EXAMPLE SSH REMOTE LOGIN OUTPUT: "tail /var/log/auth.log"

Dec  3 21:24:31 StarParty sshd[66702]: Failed password for root from 51.210.122.207 port 45722 ssh2
Dec  3 21:24:32 StarParty sshd[66702]: Received disconnect from 51.210.122.207 port 45722:11: Bye Bye [preauth]
Dec  3 21:24:32 StarParty sshd[66702]: Disconnected from authenticating user root 51.210.122.207 port 45722 [preauth]
Dec  3 21:24:38 StarParty sshd[66712]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=150.158.171.64  user=root
Dec  3 21:24:40 StarParty sshd[66712]: Failed password for root from 150.158.171.64 port 55444 ssh2
Dec  3 21:24:41 StarParty sshd[66721]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=142.93.34.237  user=root
Dec  3 21:24:41 StarParty sshd[66712]: Received disconnect from 150.158.171.64 port 55444:11: Bye Bye [preauth]
Dec  3 21:24:41 StarParty sshd[66712]: Disconnected from authenticating user root 150.158.171.64 port 55444 [preauth]
Dec  3 21:24:44 StarParty sshd[66721]: Failed password for root from 142.93.34.237 port 58226 ssh2
Dec  3 21:24:44 StarParty sshd[66721]: Received disconnect from 142.93.34.237 port 58226:11: Bye Bye [preauth]
Dec  3 21:24:44 StarParty sshd[66721]: Disconnected from authenticating user root 142.93.34.237 port 58226 [preauth]
Dec  3 21:25:00 StarParty sshd[66728]: Unable to negotiate with 218.92.0.212 port 45440: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1 [preauth]
Dec  3 21:25:01 StarParty CRON[66730]: pam_unix(cron:session): session opened for user root by (uid=0)
Dec  3 21:25:01 StarParty CRON[66730]: pam_unix(cron:session): session closed for user root
Dec  3 21:25:26 StarParty sshd[66776]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=150.158.171.64  user=root
Dec  3 21:25:27 StarParty sshd[66776]: Failed password for root from 150.158.171.64 port 33534 ssh2
Dec  3 21:25:30 StarParty sshd[66776]: Received disconnect from 150.158.171.64 port 33534:11: Bye Bye [preauth]
Dec  3 21:25:30 StarParty sshd[66776]: Disconnected from authenticating user root 150.158.171.64 port 33534 [preauth]

"tcpdump -A"

curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256...Arsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519...lchacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com...lchacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com....umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1....umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1....none,zlib@openssh.com....none,zlib@openssh.com.......................
21:27:59.780431 IP 46.101.194.220.40238 > starparty.ssh: Flags [.], ack 1098, win 501, options [nop,nop,TS val 431378467 ecr 1031716663], length 0
21:27:59.781114 IP 46.101.194.220.40238 > starparty.ssh: Flags [P.], seq 22:462, ack 1098, win 501, options [nop,nop,TS val 431378471 ecr 1031716663], length 440
fcurve25519-sha256@libssh.org,ecdh-sha2-nistp256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1...#ecdsa-sha2-nistp256,ssh-rsa,ssh-dss...daes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc,3des-cbc,des-cbc-ssh1...daes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc,3des-cbc,des-cbc-ssh1...   hmac-sha1...    hmac-sha1....none....none......
21:27:59.781131 IP starparty.ssh > 46.101.194.220.40238: Flags [.], ack 462, win 507, options [nop,nop,TS val 1031716853 ecr 431378471], length 0
21:27:59.983564 STP 802.1d, Config, Flags [none], bridge-id 8000.14:cc:20:b5:54:68.8003, length 35

Other help I've found is... https://help.ubuntu.com/community/IptablesHowTo

Andrew Schulman
  • 8,561
  • 21
  • 31
  • 47
Asher
  • 101
  • 3
  • 2
    Welcome to the Internet. All those IPs are very real. And dealing with constant attacks is part of being on the Internet. – Michael Hampton Dec 04 '20 at 11:32
  • There is protection in the Linux kernel against IP spoofing, so the description isn't accurate. The question really is, "how can I protect my server from SSH brute force login attempts". Fail2ban is likely your best option. – labradort Dec 04 '20 at 13:28
  • unfortunately i DONT want to install more software.. I am just looking for something easy to modify... for example "sudo systemctl restart ssh.service" and "/etc/ssh/ssh_config " – Asher Dec 04 '20 at 16:50
  • 1
    Why don't you want to solve your problem with the proper tools? – Michael Hampton Dec 04 '20 at 17:07

3 Answers3

2

You can try to use the program Fail2Ban https://www.fail2ban.org/wiki/index.php/Main_Page

That will automatic block the source IP from failed login attemtps.

It is working quite well, and you have a lot of options to configure it too. Like how many attepmts before get banned or how long it will be banned.

But you should consider if you really want to have SSH-open for the whole world. So if your machine is connected to Internet directly, I would recommend to use a firewall, with everything blocked by default. And open for ssh-only from that IP you need to be open.

toed
  • 156
  • 1
  • unfortunately i DONT want to install more software.. I am just looking for something easy to modify... for example "sudo systemctl restart ssh.service" and "/etc/ssh/ssh_config " – Asher Dec 04 '20 at 16:50
  • the other problem with "Fai2Ban" is that it blocks the IP address.. this is wrong? because the IP address is spoofed.. so for example say the attacker uses a "good" ip address to try and mess up remote logins for the system? and then in the future you can login from the other IP? – Asher Dec 04 '20 at 16:58
  • There is no basis for your claim "the IP address is spoofed". Try this: cat /proc/sys/net/ipv4/conf/default/rp_filter If the result is '1', then you have source address verification already enabled in the kernel. All modern Linux have this setting by default. – labradort Dec 04 '20 at 18:11
1

There are a few things which can take away the security risk of having SSH open to the world.

  • Fail2ban (mentioned already) is good. It supports blocking permanently or just for some time in the firewall.

  • Run SSH on a weird high level port, something above 8000. This doesn't stop anything, but there is a great reduction in traffic, since most script kiddies are probing port 22.

  • Ensure PermitRootLogin in sshd_config is not running with the value Yes. You don't need root logins happening over ssh. You can ssh in as a regular user then su. This way, there are two passwords needed to gain admin access (unless this is Ubuntu or similar, where a regular user has sudo powers).

  • Consider dual factor authentication. This can be done with commercial products like Duo, or using something like Google authenticator. The steps for that set up would come from the vendor.

  • Have email sent when there is a successful login. This allows you to know immediately if there is access, before a hacker has possibly had a chance to destroy any safe guards you've put in place. To do this, you need a session line added to /etc/pam.d/sshd that would look something like this:

    session required pam_exec.so /root/scripts/send-ssh-notice.sh

    There is a sample of a script that can provide the details in variables, and it is available at github: Github hosted sshlogin_alert.sh

    (Yes, I have provided a link in my answer, and why not? Github code is maintained, supports forks, and has good feedback. My posted answer will not be revisited by me in months or years ahead. In addition, credit should be given where it is due and this Github user has done a good job.)

labradort
  • 1,169
  • 1
  • 8
  • 20
0

SAD.. so SO SAD?

i might just have to "stop my sshd server"?

:(

Perhaps there is some "SIMPLE" way without installing additional software?

This doesn't solve the problem yet.. but I think its on the correct path?

sudo gedit /etc/ssh/ssh_config 
sudo systemctl restart ssh.service

Here is what the "ssh_config" looks like...

Include /etc/ssh/ssh_config.d/*.conf

Host *
# PermitRootLogin no
#   ForwardAgent no
#   ForwardX11 no
#   ForwardX11Trusted yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   GSSAPIKeyExchange no
#   GSSAPITrustDNS no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   IdentityFile ~/.ssh/id_ecdsa
#   IdentityFile ~/.ssh/id_ed25519
Port 22
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,umac-64@openssh.com
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
#   ProxyCommand ssh -q -W %h:%p gateway.example.com
#   RekeyLimit 1G 1h
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes

There is also some modification to the "iptable" that is possible?

Asher
  • 101
  • 3
  • If you are connecting from a predictable IP address, you could make iptables rule to accept only SSH connections from an IP. If you are going to be connecting from places like cafes, then this isn't possible. The IPs are going to be different and change over time. The iptables rule you listed doesn't do anything other than open up port 22 to the world. To restrict it to a specific IP, you could add -s and then the IP address in the iptables. You also need an iptables configuration to DROP everything not in the iptables ACCEPT rules. iptables is a big topic. Don't lock yourself out. – labradort Dec 04 '20 at 18:27