# hacking SSH server



## jack111 (Nov 8, 2011)

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 (Nov 8, 2011)

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 (Nov 8, 2011)

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 8, 2011)

```
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 (Nov 8, 2011)

*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 (Nov 8, 2011)

jack111 said:
			
		

> ... 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 (Nov 9, 2011)

jack111 said:
			
		

> 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 (Nov 9, 2011)

@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 (Nov 9, 2011)

*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 (Nov 9, 2011)

jack111 said:
			
		

> 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. 



			
				jack111 said:
			
		

> 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 (Nov 9, 2011)

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 (Nov 9, 2011)

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 (Nov 9, 2011)

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.


----------

