
Troubleshooting 74
Nmap run completed -- 1 IP address (1 host up) scanned
in 169 seconds
to check if any ports are open that should normally be closed.
That could however be a problem to remove a rootkit from a VPS and make sure it is 100%
removed. If you're not sure, create a new VPS for that customer and migrate her data there.
Check the
/var/log/
directory on the Hardware Node to find out what is happening on
the system. There are a number of log files that are maintained by the system and OpenVZ
(the
boot.log
,
messages
,
vzctl.log
log files, etc.), but other services and programs
may also put their own log files here depending on your distribution of Linux and the
services and applications that you are running. For example, there may be logs associated
with running a mail server (the
maillog
file), automatic tasks (the
cron
file), and others.
However, the first place to look into when you are troubleshooting is the
/var/log/messages
log file. It contains the boot messages when the system came up
as well as other status messages as the system runs. Errors with I/O, networking, and other
general system errors are reported in this file. So, we recommend that you turn to the
messages
log file first and then proceed with the other files from the
/var/log/
directory.
Subscribe to bug tracking lists, at least for Red Hat. You should keep track of new public
DoS tools or remote exploits for the software and install them into VPSs or at Hardware
Nodes.
When using
iptables
, there is a simple rule for Chains usage to help protect both the HN
and its VPSs:
use INPUT, OUTPUT to filter packets that come in/out the HN;
use FORWARD to filter packets that are designated for VPSs.