I'm using Windows 7 and decided to learn Linux Administration (Centos 6.4) using Oracle VirtualBox to host the Linux system.

In my network configuration I choose "Bridged Adapter". I set the VM's IP to and my Windows host is As I do not have much RAM I did everything using SSH. SSH was set to the default (port 22, root login allowed). I also set on my router DMZ to this VM to be able to use this VM from everywhere.

Today I have checked logs (/var/log/messages, /var/log/auth) and found that few IPs tried to logon to my server and some of them succeeded. Although I have nothing important on this server, I am wondering if someone could get to my Windows environment (the host) or set sth on my local network to spy on my real system. I have no knowledge in this field and I would like to know if my windows system is somehow in danger.

For the time being, I have disabled ssh to my server.

  • There was a an interesting talk about the difficulties of securing a VM against a malicious guest on the Chaos Communication Congress in Germany last December. Virtually Impossible: The Reality Of Virtualization Security. Too long didn't watch: Virtualization is a lot more complex than it seems. Complexity means room for bugs. Bugs mean attack points for breaking out of the VM.
    – Philipp
    Jan 7, 2014 at 21:03

2 Answers 2


The short answer is "Yes, anything is possible."

The long answer is "Maybe, but without more information it's virtually impossible to tell."

You should consider that CentOS VM compromised, remove it from your network and also check the logs on any other systems that were online / connected at the time the unauthorized access occurred.

First, here's something to get you started with CentOS security - one of the first google results for "CentOS hardening":


This is a pretty decent slideshare with configuration examples and explanations.

Secondly, consider using port-forwarding instead of exposing that machine completely to the outside world: forward only the ports you absolutely need.

Thirdly, set SSH to use Public/Private keys for authentication instead of passwords:


Using Public/Private key authentication with SSH ensures that no one will just be able to "guess" your password: they'll need your private key.

  • Hmm, when I think about it, the server was exposed for some time now. I have shut it down and will reinstall it to avoid any unpleasent suprises. I have also disabled DMZ and enabled port forwarding for few ports. Now it's time to search something in Windows logs.
    – bastek
    Jan 7, 2014 at 20:40

The good the bad and the ugly. Depending on which account they logged into, all they would need to do (say as root) is run a packet capture to see anything else on the network. Imagine the following for a moment. You are in a room (network), other people are in the same room (virtualization), and you place a tap recorder to record everything (sniffer).

Its already been mentioned to find hardening documentation, my suggestion differs a bit. Learn firewalling ;) Because your Linux device has its own firewalls, now is a good time to familiarize yourself with creating rules. "Block anything from this address, to my address, on this port." Obviously, shut down services you don't need, and keep things separated password wise. For example, if your normal password is bastek1234 for say your Windows machine, I don't suggest you re-use passwords.

You exposed your machine to the world, so expect garbage to hit you. Now is also a good time to play with cron, and scripting languages. For example, write your own alerting system:

tail -n 1000 /var/log/auth | grep -i failure | mail -s "Failed Attempts" [email protected]

There are plenty of mechanisms you can take the initiative on once you have an idea of what you need to do. Don't always rely on "hardening" guides as those change. I have written hardening guides dating back to 1996 to which I chuckle now at how much things have changed.

As for busting out of VMWare, there is Cloudburst ;) http://www.google.com/search?q=cloudburst+immunity+%2Bcanvas&oe=utf-8&rls=org.mozilla%3Aen-US%3Aofficial&client=firefox-a&oq=cloudburst+immunity+%2Bcanvas&gs_l=heirloom-serp.3...10278.11859.0.11955.


You don't need to log in as root ever. That is what sudo is for. And if sudo isn't enough, you could slap on Duosecurity to ONLY allow commands after it has called your mobile/landline to validate you are who you say you are. As for logins, you may parse through your .*_history files to see what was done provided they didn't erase the logs

  • I made so many mistakes on so many levels. I don't remember why I turned off my firewall (iptables). As my server has nothing to offer I thought, who would like to get in to it. As I can see, a lot of people checked if I am security aware. I looked through /var/log/messages and found that 2 IPs succesfully logged on as root. I am not sure how much information this log file has but on of the "guest" created account ".php" with uid=0 and changed my root pass. Yesterday I actually could not logon to my server as root and I thought that I forgot my pass, so I decided to reset it.
    – bastek
    Jan 7, 2014 at 21:40
  • to learn from one's mistakes - perfectly match my situation. I think that it gave me a lot of security awarness. Now it's time to prepare VM once again but now I will take all yours advices under consideration.
    – bastek
    Jan 7, 2014 at 21:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .