That little problem experienced by Cryptome.org’s sysadmin got me thinking, how does one host 70,000+ publicly-available documents and deal with an attacker that uses wget to scrape the entire site every 24 hours? Was this a Denial of Service designed to eat up bandwidth allowance, or was it some intelligence gathering effort related to the NSA leak?
It just so happened that I recently discovered xinetd (Extended Network Daemon) and have been experimenting with it. It’s basic stuff I should have known already, xinetd being a core component that kills several birds with one stone on a UNIX system.
Background and History: inetd
The manpage for this daemon states:
‘Instead of having such servers started at system initialization time, and be dormant until a connection request arrives, xinetd is the only daemon process started and it listens on all service ports for the services listed in its configuration file. When a request comes in, xinetd starts the appropriate server.’
To really appreciate its role in securing the OS against network-based threats, we first need an understanding of the more conventional inetd. This is a component of UNIX that manages network-enabled services – primarily it launches a specific program when an incoming request is received.
Ports are mapped to generic service names (not the programs themselves) in /etc/services. The file /etc/inetd.conf maps those services to whatever programs handle them on the local system, although it seems the package manager removed this when replacing the daemon with xinetd.
For most users the contents of these files shouldn’t change, unless programs are installed/removed or the system’s being hardened to function as a bastion host. Pretty straightforward to understand.
Extended inetd, or xinetd
Where xinetd differs from the older daemon is the functionality – when properly configured, xinetd has a number of features that protect the local system from network-based threats, and by implication mitigates the effects of certain malware. These are listed on the official xinetd site.
Apart from using different configuration files than inetd (/etc/xinetd.conf and /etc/xinetd.d for program-specific settings), xinetd does exactly the same but enables granular access controls to be set, for example limiting the number of programs running simultaneously, limiting the number of incoming connections, etc. Now we can start to see its use as a host-based intrusion prevention system and one possible way of dealing with Denial of Service attacks.
After installation, there should be a configuration file for the daemon in /etc/init, indicating that it’s launched in place of the older inetd when the system enters runlevel 2. Configuration is simple enough, if we understand the format and what each field means. A service’s entry will look something like:
service imap
{
socket_type = stream
protocol = tcp
wait = no
user = root
only_from = 198.72.5.0 localhost
banner = /usr/local/etc/deny_banner
server = /usr/local/sbin/imapd
}
Creating a log file for xinet is also straightforward. In the command line, enter:
$xinetd -filelog xlog.txt
This creates a log file called xlog.txt in the user’s home directory. Out of the box, the daemon should produce something like:
But no services or logging policies have been added to xinetd.conf yet. To start logging, add log_on_failure and log_on_success to whatever services along with values to define what to record. Logging (and a few other parameters) can also be set globally for all services with the xinet.conf entry:
defaults
{
instances = 25
log_type = FILE /var/log/servicelog
log_on_success = HOST PID
log_on_failure = HOST RECORD
disabled = tftp
}
Denial of Service and Related Stuff
Back to the original problem, this is quite easily solved with xinetd configured as an Intrusion Prevention System. Most DoS attacks (basic definition here) involve sending continuous requests to a server with the aim of disrupting whatever service, perhaps by sending more requests than the server can handle, or by consuming processor and memory resources. Or perhaps both. The scraper targeting Cryptome.org would be a classic example, if it manages to take the site offline by exhausting its bandwidth allowance. We therefore want to configure it in a way that handles this. Here are some of the parameters we could use:
* per_source: Max number of services that a source IP address can access at once.
* deny_time: Discontinue access to a service for a source that sets off a SENSOR flag.
* cps: Connections per second allowed for a service. This is suffixed with time delay for restarting the service.
In addition, there are resource limiting parameters that restrict the memory, CPU, etc. usage for a service. These are also very important, to prevent the system becoming so totally screwed it’s unmanageable.
And what about a DDoS? Well, the effects of all but the largest botnet could also be mitigated with some careful planning – ideally the service would be hosted on a reasonably high-spec system functioning as a bastion host, and xinetd configured in such a way that makes each attacking host almost insignificant.
The Krypt 