- Users can consume excessive resources resulting in 'denial of service(s)'.
- Controlling/limiting what resources users are allowed can reduce this possibility.
Shell resources - ulimit
ulimit [-SHacdefilmnpqrstuvx] [limit]
-H Hard limit
-S Soft limit
If neither '-S', '-H' are specified, both are set
-a All current limits are reported
-c The maximum size of core files created
-d The maximum size of a process's data segment
-e The maximum scheduling priority ("nice")
-f The maximum size of files written by the shell and its children
-i The maximum number of pending signals
-l The maximum size that may be locked into memory
-m The maximum resident set size
-n The maximum number of open file descriptors (most systems
do not allow this value to be set)
-p The pipe size in 512-byte blocks (this may not be set)
-q The maximum number of bytes in POSIX message queues
-r The maximum real-time scheduling priority
-s The maximum stack size
-t The maximum amount of cpu time in seconds
-u The maximum number of processes available to a single user
-v The maximum amount of virtual memory available to the shell
-x The maximum number of file locks
Display current (in my case default) shell limits
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 20
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
- Any unlimited setting makes the system more vulnerable to Denial of Service (DoS) attacks.
- One setting to note is core file size (blocks, -c) 0. If you are running a stable system you should not really need core files - can always be 'enabled' if the need arises.
- Core files can increase a systems vulnerability to DoS if their size is not constrained. They also provide a lot of low-level information that may be of use to an attacker.
Always remove the compiler(s) from any production machine. Usually with Linux, the default is to have 'gcc' installed.
Mount volumes as noexec
If certain volumes/filesystems are available to users e.g. an upload directory on a web or ftp server, it is common practice to mount these as 'noexec'. This protects against simple scripted file-drop attacks.
Further enhance a 'chrooted' ftp server - /etc/fstab
/dev/sda6 /ftpsvr ext3 defaults 0 0
/dev/sda7 /ftpsvr/etc ext3 noexec,nosuid,ro 0 0
/dev/sda8 /ftpsvr/bin ext3 ro 0 0
/dev/sda9 /ftpsvr/data ext3 noexec, nosuid 0 0
May look something like this.
Configure appropriate logging
Enable appropriate logging via Syslog, rsyslogd. There are several open source tools that enhance logging e.g. swatch, scanlogd, ...