Setting instances and per_source to UNLIMITED in Linux, does it make system vulnerable

[Bishwajit Kumar]

Setting instances and per_source to UNLIMITED in Linux, does it make system vulnerable to security attack???


RHEL 5.5 x86_64
/etc/xinetd.conf
instances = UNLIMITED (default is 50)
per_source = UNLIMITED (default is 10)

SLES 11 SP1 x86_64
/etc/xinetd.conf
instances = UNLIMITED (default is 30)
and by default per_source is not listed in the xinetd.conf file.

Thanks,
~Bish

[Matti_Kurkela · Accepted solution]

Yes, it increases the vulnerability to denial-of-service attacks.

Think about what happens if a malicious person writes a program that rapidly opens e.g. 50 000 connections to one xinetd service. If the limits are set to UNLIMITED, then xinetd will dutifully try to start up 50 000 processes, one for each connection.

Your system will be *really* slow for a while; if the process table fills up, nobody will be able to log in and some important system daemons might crash. Not a good thing.

Resource limits like this exist to allow the system to gracefully reject attempts to overload it, instead of "going down fighting" trying to serve an impossible amount of requests.

MK

[Bishwajit Kumar]

Thank You Matti.

[Bishwajit Kumar]

Matti,

For RHEL instances and per_source both are defined (50 & 10 respectively) bug for SLES only instances is defined (30) that meas per_source is considered as UNLIMITED, isn't it.

Though it is again limited by total number of instances to 30. So having per_source = UNLIMITED or commenting it is not really a big problem as over all instances limited.

correct me if i am wrong please.

RHEL 5.5 x86_64
/etc/xinetd.conf
instances = UNLIMITED (default is 50)
per_source = UNLIMITED (default is 10)

SLES 11 SP1 x86_64
/etc/xinetd.conf
instances = UNLIMITED (default is 30)

And if the system is behind the firewall in production for the Backup (as Media Server), where backup need to be run as multiple streams of backup concurrently; what is your advice? Set to UNLIMITED or set it as per requirement?


Thanks,
~Bishwajit

[Bishwajit Kumar]

>> hink about what happens if a malicious
>> person writes a program that rapidly opens
>> e.g. 50 000 connections to one xinetd
>> service. If the limits are set to UNLIMITED,
>> then xinetd will >>dutifully try to start
>> up 50 000 processes, one for each
>> connection.

A quick question?

To do so does that person has to have the root or any other user access or knowing an IP address of the system is enough to abuse UNLIMITED instances/per_source???

Please respond.

[Matti_Kurkela]

You're correct about the difference between RHEL and SLES: I'd say RHEL's defaults allow for more legitimate uses in parallel, while placing a stricter limit against abuse than SLES. But both are good enough.

Of course, if you're setting up some service that will have more than about 30 simultaneous users, you'll have to change these settings... but xinetd allows you to change the settngs separately for each service, in the service definition files in /etc/xinetd.d/. The defaults are just a starting point: a safe limit for services you're just testing or otherwise haven't felt the need to define specific limits yet.

> And if the system is behind the firewall in production for the Backup (as Media Server), where backup need to be run as multiple streams of backup concurrently; what is your advice? Set to UNLIMITED or set it as per requirement?

I'd expect the presence of a firewall to mean that the risk of an external attack from the Internet is minimized/eliminated. So the limit would exist to protect against firewall misconfigurations, other mistakes and malicious internal users.

I'd find out a rough estimate of the number of connections the backup system needs (perhaps one stream for each filesystem on the host + a fixed number of control streams?), then multiply this limit by maybe 5x or 10x. That should leave plenty of room for capacity expansion, and yet provide reasonable protection against malice or malfunctioning software.

> To do so does that person has to have the root or any other user access or knowing an IP address of the system is enough to abuse UNLIMITED instances/per_source???

No account on the target system is needed. Xinetd does not do authentication at all: any authentication would be the responsibility of the service process started by xinetd. The abuser only requires the knowledge that an abusable port exists and the ability to reach it.

A requirement for authentication would not help; in a denial-of-service attack, the attacker is not interested in logging in or actually using the service in any way. The only objective is to make your system spend as much time as possible in processing nonsense requests.

MK

[Bishwajit Kumar]

Thanks MK