First, make sure the computer is disconnected from any networks.
Second, make sure you get any important data off the drives before booting the hacked OS again.
Start with checking out the time stamps on the files in question. Often they are accurate.
Cross reference those with the httpd log and the auth log if they weren't wiped. If one other the other was wiped, you can bet that was the means of entry. If they're still in tact, you might be able to glean more information on how they got in from the log.
If they're all wiped, you're pretty screwed. It would likely take more time to figure out what happened than it's worth.
You mentioned those two services were running, was there a good firewall in place to prevent everything else from being accessed? Did you allow SSH on port 22; is your login reasonably easy to guess; did you allow password logins; did you have any sort of real rate limiting for password logins? Did you have any additional software installed with lighttpd; perl; php; cgi; a CMS or similar? Were you running updated version of all the software; do you subscribe to security notifications for all the software you run and carefully evaluate all notifications to see if they apply to software you run/expose to the public?
I'll start by saying this, if you have NO LOG FILES, then there is a reasonably good chance that you will NEVER understand where or how the attack succeeded. Even with full and proper log files, it can be extremely difficult to understand fully, the who, what, where, when, why and how.
So, knowing how important log files are, you begin to understand just how safe you have to keep them. Which is why companies do and should be investing in Security Information & Event Management or SIEM for short.
In a nutshell, correlating all of your log files into specific events (time-based or otherwise) can be an extremely daunting task. Just take a look at your firewall syslogs in debug mode if you don't believe me. And that's just from one appliance! A SIEM process puts these log files into a series of logical events which makes figuring out what happened, much easier to understand.
To begin to have a better understanding of the how, it's helpful to study penetration methodologies.
It's also helpful to know how a virus is written. Or how to write a rootkit.
It can also be extremely beneficial to setup and study a honeypot.
It also helps to have a log parser and become proficient with it.
It's helpful to gather a baseline for your network and systems. What's "normal" traffic in your situation vs. "abnormal" traffic?
CERT has an excellent guide on what to do after your computer has been hacked, most notably (which directly pertains to your specific question) the section on "Analyze the intrusion":
- Look for modifications made to system software and configuration files
- Look for modifications to data
- Look for tools and data left behind by the intruder
- Review log files
- Look for signs of a network sniffer
- Check other systems on your network
- Check for systems involved or affected at remote sites
There are many questions similar to yours that have been asked on SF:
- How to do a post-mortem of a server hack
- Strange Items in Hosts File and Netstat
- is this a hack attempt?
- How can I learn Linux from hacking or security point of view
This can be an extremely convoluted and involved process. Most people, me included, would just hire a consultant if it got any more involved than what my SIEM appliances could put together.
And, apparently, if you ever want to FULLY understand how your systems were hacked, you have to spend years studying them and give up women.
Best Answer
Yes, but this doesn't actually mean anything; it only says a TCP connection was established and then closed. There is no relationship with what the remote user was or was not able to do.
Case in point: you connect to a remote host using SSH, then you provide wrong credentials; the server will close the connection. A connection closed by the server will go (for a while) in a FIN-WAIT-1 state. But nobody actually logged it, it was simply a failed login attempt.
If you catch one of those attempts immediately after it failed, a socket in the FIN-WAIT-1 state is exactly what you would see at the network level.
Having said all of the above, you should put some kind of firewall in front of your server (or at the very least configure the system firewall to only allow logins from known, trusted sources); if you leave any computer exposed to the public Internet on common remote administration ports (SSH, RDP, etc.), you are just asking for troubles.