hacking SSH server

[jack111]

I ran the command
netstat -an | grep "ESTABLISHED"

And found an unknow ip address with an established connection on port 22 as below

netstat -an | grep "ESTABLISHED"
tcp4     0    656  hostipaddress      hackeripaddress.46715  ESTABLISHED

The server remains unchanged with nothing to suggest anything malicious has been done.

To establish such a connection one would need the admin password thus would mean the server has been hacked into. Is there an alternative explanation to the above established connection.

Thanks.

 

[kpa]

No, one can just do $ telnet myhost 22 and just let it sit there until the timeout, that's still an established connection in TCP terms.

What does /var/log/auth.log say about that ip address?

 

[ecazamir]

You can have this 'ESTABLISHED' session even on the SSH connection startup, before SSL handshake. Try running

client$ telnet server 22

then look into the server for 'ESTABLISHED' ssh connections:

server# netstat -an | grep ESTAB | grep 22
tcp4       0      0 se.rv.e.r.22     cl.ie.n.t.28505    ESTABLISHED

On the client you might see the following:

Trying se.rv.e.r...
Connected to se.rv.e.r.
Escape character is '^]'.
SSH-2.0-OpenSSH_5.4p1 FreeBSD-20100308

If you suspect a bruteforce attack, install and configure security/sshguard or security/py-fail2ban

 

[jack111]

Nov  6 03:00:29 ServerID sshd[22022]: error: PAM: authentication error for illegal user stud from HackerIP
Nov  6 03:00:29 ServerID sshd[22022]: Failed keyboard-interactive/pam for invalid user stud from HackerIP port 60677 ssh2
Nov  6 03:00:29 ServerID sshd[22022]: Failed password for invalid user stud from HackerIP port 60677 ssh2

There are in total 804 such occurences.

Did the below as suggested

client$ telnet server 22

Sure enough even without being logged in it shows as an established connection.
Thanks

 

[jack111]

pf firewall

# brute force blocking
pass quick proto { tcp, udp } from any to any port ssh keep state (max-src-conn 20, max-src-conn-rate 6/60, overload <bruteforce> flush global)
pass inet proto tcp from any to port $tcp_services keep state  (max-src-conn 100, max-src-conn-rate 30/5, overload <bruteforce> flush global)

have a pf firewall but the above did not seem to stop it.

 

[Anonymous]

... have a pf firewall but the above did not seem to stop it.

Because of all these dictionary attacks, I am running my sshd's at different ports, since almost a year. This is of course not the perfect security measure, and of course, I am still relying on strong passwords, anyway, this measure effectively stopped these idiotic bots filling my /var/log/auth.log.

In file /etc/ssh/sshd_config one would change the line

#Port 22

to for example (I use something else, as you should do)

Port 666

The ssh command needs to be modified with the -p option and scp with the -P option. For example:
ssh -p666 [email]user@myhome.net[/email]

Best regards

Rolf

 

[SirDice]

have a pf firewall but the above did not seem to stop it.

Those rules only prevent a client from connecting when the attacker uses a high number of connections within a small period of time. It does nothing to combat a slow but constant barrage of single connection attempts.

Ecazamir already mentioned it, install security/sshguard-pf. Works like a charm.

 

[anomie]

@jack111, to add just a couple points to this thread (in no particular order).

On FreeBSD systems, there's a good alternative for determining connected IPv4 / TCP sessions:
# sockstat -4c

---

As several folks have already mentioned, a TCP handshake is established before the ssh key exchanges and authentication attempts begin. So for you to spy an established TCP session on your system is neither unusual, nor cause for alarm. (But it's good that you are monitoring.)

---

WRT the problem of low and slow attacks (i.e. distributed brute force account/password guessing), your best tool to combat it is simply not having a 'net-facing sshd(8) service. If your situation legitimately requires one, then I suggest enforcing strong passwords with pam_passwdqc(8), monitoring logs regularly, and keeping up to date with system updates and patches. (There are many ways to mitigate risks above and beyond that, but better have your fundamentals in place before getting complicated.)

 

[jack111]

well I must be really hacked than

Ran the command
[CMD=""]sockstat -4c[/CMD]

USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS      
root     perl5.8.9  92535 10 tcp4   MYServerIP:10000    Myremoteipaddres:1397
sshd     sshd       92531 3  tcp4   MYsecondserverIP:22       HackerIP:64358
root     sshd       92530 3  tcp4   MYsecondserverIP:22       HackerIP:64358
sshd     sshd       92529 3  tcp4   MYthirdserverIP:22       HackerIP:45900
root     sshd       92528 3  tcp4   MYthirdserverIP:22       HackerIP:45900

Got the above does this mean the hacker has managed to connected to my server?

my SSH admin and root passwords are about 40 characters a mixture of alphabets with capitals, numbers and symbols. I doubt very much any brute force attack could guess this password.
The Root and Admin passwords were just changed yesterday to the 40 plus alphanumeric passwords.

 

[anomie]

Got the above does this mean the hacker has managed to connected to my server?

Again, this means that clients have completed a TCP handshake with your server (and are waiting for a FIN or a timeout). This is totally different than successfully authenticating.

The Root and Admin passwords were just changed yesterday to the 40 plus alphanumeric passwords.

Nice. If you have other users on the system, be sure you're enforcing strong passwords, as I mentioned.

 

[kpa]

It may be a bit of work but best option is to disable root logins via ssh, disable password logins from the outside world and require RSA key authentication on those connection coming from the outside.

/etc/ssh/sshd_config

...
PermitRootLogin no
PasswordAuthentication no
UsePAM no
ChallengeResponseAuthentication no

Match Address 192.168.0.0/24 # replace with your local network address range
  PasswordAuthentication yes
...

How to create and use RSA keys with ssh:

http://www.freebsd.org/doc/handbook/openssh.html

ssh-keygen(1), ssh-agent(1), ssh-add(1)

 

[jack111]

I thought
[CMD=""]sockstat -4c[/CMD]
showed establised connections i.e. connections which were successful. This I know now is wrong.
Will check the logs

Root logins already disabled.

Will be installing security/sshguard-pf as suggested.

 

[DutchDaemon]

There is a difference between an established connection on the TCP/IP level (for tcp: SYN, SYN/ACK, ACK) and on the application level. What you are seeing are established connections to tcp port 22, nothing more. That does not mean that the 'sshd hurdle' (authentication) has actually been crossed. In other words: you see an established connection to the daemon, not an authorized connection to the actual system behind it.