harrygittens wrote:hi
do grsec have any fork rate limiting any more. i always thought it did.
Yes, to some extent. CONFIG_GRKERNSEC_BRUTE:
"attempts to bruteforce exploits against forking
daemons such as apache or sshd will be deterred. When a child of a
forking daemon is killed by PaX or crashes due to an illegal
instruction, the parent process will be delayed 30 seconds upon every
subsequent fork until the administrator is able to assess the
situation and restart the daemon. It is recommended that you also
enable signal logging in the auditing section so that logs are
generated when a process performs an illegal instruction."
If resource limits are configured properly, this feature stops most
of fork bombs, because what grsec checks for is the rate of the _failed_
forks (the actual reason of failure is not important). So when, say,
RLIMIT_NPROC is overstepped, fork() start to fail, and all the forking
processes are forcibly put to sleep...
reason is because we have shell access for users. they are limited to 15
procs through /etc/security/limits.conf. grsec is enabled and on high too.
The limits specified in
/etc/security/limits.conf apply only to the processes started in a PAM
session, (e.g. user shells). Daemons escape this restrictions since
they are started directly by init. To restrict them one has to expilcitly
specify resource limits in the startup scripts. Details depend on your
distribution, init, and the daemon itself.
I use runit (
http://smarden.org/runit) as init. Here is the startup
script of the web server (thttpd,
http://www.acme.com/software/thttpd):
- Code: Select all
$ cat /etc/sv/thttpd/run
#!/bin/sh
CONFFILE=/etc/thttpd/thttpd.conf
if [ ! -f $CONFFILE ]; then
exit 1
fi
# Run with nice value
NICE='-n 15'
# Limit number of concurrently running CGIs
NPROC='-p 10'
# Limit the VM available to the daemon to 600Mb
MEM='-m 629145600'
exec chpst $NICE $NPROC $MEM /usr/sbin/thttpd -D -C $CONFFILE
For Sys V init your need to stick ulimit -u NPROC
(and ulimit -u VMSIZE) into /etc/init.d/httpd (or whatever it is on
your system).
the normal bash fork bombs and c fork() don't work, but this cmd is
killing our system:
- Code: Select all
python -c 'while 1: __import__("os").fork()'
Interesting. I've just tried it on my system. The thing stopped after
complaining about fork failures (so presumably grsec works as advertised)
- Code: Select all
$ ulimit -a
core file size (blocks, -c) 16384
data seg size (kbytes, -d) 1048576
max nice (-e) 38
file size (blocks, -f) unlimited
pending signals (-i) unlimited
max locked memory (kbytes, -l) 262144
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 16384
max rt priority (-r) 99
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 60
virtual memory (kbytes, -v) 524288
file locks (-x) 1024
$ python -c 'while 1: __import__("os").fork()'
Traceback (most recent call last):
Traceback (most recent call last):
File "<string>", line 1, in ?
OSError: [Errno 11] Resource temporarily unavailable File "<string>", line 1, in ?
OSError: [Errno 11] Resource temporarily unavailable
Traceback (most recent call last):
File "<string>", line 1, in ?
OSError: [Errno 11] Resource temporarily unavailable
Traceback (most recent call last):
File "<string>", line 1, in ?
OSError: [Errno 11] Resource temporarily unavailable
Traceback (most recent call last):
File "<string>", line 1, in ?
OSError: [Errno 11] Resource temporarily unavailable
Traceback (most recent call last):
File "<string>", line 1, in ?
OSError: [Errno 11] Resource temporarily unavailable
Traceback (most recent call last):
-bash: fork: Resource temporarily unavailable
File "<string>", line 1, in ?
OSError: [Errno 11] Resource temporarily unavailable
Traceback (most recent call last):
Traceback (most recent call last):
File "<string>", line 1, in ?
P.S.
@moderator I apologize for being slightly off topic, but I don't like
RTFM as an answer.
