Posts Tagged ‘memory size’

Linux: Limiting user processes to prevent Denial of Service / ulimit basics explained

Monday, May 20th, 2013

Linux limiting max user processes with ulimit preventing fork-bombs ulimit explained

To prevent from various DoS taking advantage of unlimited forks and just to tighten up security it is good idea to limit the number of maximum processes users can spawn on Linux system. In command line such preventions are done using ulimit command.

To get list of current logged in user ulimit settings

hipo@noah:~$ ulimit -a

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 16382
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

As you see from above output, there is plenty of things, that can be limited with ulimit.
Through it user can configure maximum number of open files (by default 1024), e.g.:

open files                      (-n) 1024

You can also set the max size of file (in blocks) user can open – through:

file size               (blocks, -f) unlimited

As well as limiting user processes to be unable to use more than maximum number of CPU time via:

cpu time               (seconds, -t) unlimited

ulimit is also used to assign whether Linux will produce the so annoying often large produced core files. Those who remember early time Linux distributions certainly remember GNOME and GNOME apps crashing regularly producing those large useless files. Most of modern Linux distrubutions has core file produce disabled, i.e.:

core file size          (blocks, -c) 0

For Linux distributions, where for some reason core dumps are still enabled – you can disable them by running:>

noah:~# ulimit -Sc 0

By default depending on Linux distribution max user processes ulimit is either unlimited in Debian and other deb based distributions or on RPM based Linuces versions of  (Fedora, RHEL, CentOS, Redhat) is 32768.

To ulimit a current logged in user to be able to spawn maximum of 50 processes;

hipo@noah:~$ ulimit -Su 50
hipo@noah:~$ ulimit -a

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 16382
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 50
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

-Su – assigns max num of soft limit to 50, to set a hard limit of processes, there is the -Hu parameter.

Imposing ulimit user restrictions, lets say a max processes user can run is set via /etc/security/limits.conf

In limits.conf, there are some commented examples, e.g., here is paste from Debian:

#*               soft    core            0
#root            hard    core            100000
#*               hard    rss             10000
#@student        hard    nproc           20
#@faculty        soft    nproc           20
#@faculty        hard    nproc           50
#ftp             hard    nproc           0
#ftp             –       chroot          /ftp
#@student        –       maxlogins       4

The @student example above, i.e.:

@student        hard    nproc           20

– sets maximum number of 20 processes for group student (@ – at sign signifies limitation is valid for users belonging to group).

As you can see there are soft and hard limit that can be assigned for user / group. soft limit sets limits for maximum spawned processes by by non-root users, soft limit can be modified by non-privileged user.
hard limit assigns maximum num of processes for programs running and only privileged user root can impose changes to that.
To add my user hipo to have limit of maximum 100 parallel running processes I had to add to /etc/security/limits.conf

hipo@noah:~$ echo 'hipo hard nproc 100' >> /etc/security/limits.conf

ulimit shell command is a wrapper around the setrlimit system call. Thus setrlimit instructs Linux kernel with interrupts depending on ulimit assigned settings.

One note to make here is whether limiting user has to use Linux system in Graphical Environment, lets say GNOME you should raise the max number of spawned processes to some high number for example at least 200 / 300 procs.

After limitting user max processes, You can test whether system is secure against fork bomb DoS by issuing in shell:

hipo@noah:~$ ulimit -u 50
hipo@noah~:$ :(){ :|:& };:
[1] 3607
hipo@noah:~$ bash: fork: Resource temporarily unavailable
bash: fork: Resource temporarily unavailable

Due to the limitation, attempt to fork more than 50 processes is blocked and system is safe from infamous denial of service fork bomb attack

Fixing common WordPress empty page error

Thursday, May 2nd, 2013

A very common error for  wordpress based blog / site  whenever you modified
something inside pluginsis to receive empty page screen on user visit.

This error often is because of any installed WordPress caching plugins like
WP SUPER CACHE

or

W3 TOTAL CACHE.

One way to solve it is to delete from wp-config/plugins/ Folder whatever plugin is
causing the troubles.

If this doesn't fix the error and you need to Debug what is causing the odd
Empty pages.
Open wp-config.php and somewhere near beginning of file include:
 

error_reporting(E_ALL); ini_set('display_errors', 1);
define( 'WP_DEBUG', true);

After saving wp-config.php and refreshing WP size in Browser
(after cleaning browser cache)

if you get an error like:

Fatal error: Allowed memory size of 8388608 bytes exhausted
(tried to allocate 252212 bytes) in
/var/www/blog/wp-includes/cache.php on line 4


This is due to set maximum System Wide memory Limit of PHP Scripts to 8MB.
To solve that raise the PHP Limit to lets say 64M from wp-config.php by adding
in it line:

define('WP_MEMORY_LIMIT', '64M');

That's all WordPress should be working normal again.

Enjoy 🙂