Archive for the tag 'denial'

SBDavid
Dec 7th, 2010

Denial of Service (DoS) Attacks

Denial of Service (DoS) Attacks

Attacker or group of attackers coordinate against an organization’s network or server resources by sending unauthorized packets to the target host (either server, router, or workstation). This forces the resource to become unavailable to legitimate users.

The most reported DoS case in the US occurred in 2000. Several highly-trafficked commercial and government sites were rendered unavailable by a coordinated ping flood attack using several compromised systems with high bandwidth connections acting as zombies, or redirected broadcast nodes.

Source packets are usually forged (as well as rebroadcasted), making investigation as to the true source of the attack difficult.

Advances in ingress filtering (IETF rfc2267) using iptables and Network Intrusion Detection Systems such as snort assist administrators in tracking down and preventing distributed DoS attacks.

SBDavid
Oct 27th, 2009

Preventing Accidental Denial of Service

Preventing Accidental Denial of Service

Linux allows you to set limits on the amount of system resources that users and groups can use.

Restricting System Resources

The following example shows a practical use of setting or restricting system resources for an database user account. For a list of system resource settings, see /etc/security/limits.conf. It would be a good idea to review the default settings of system resource.

database soft nofile 4096
database hard nofile 63536

The “soft limit” in the first line defines the number of file handles or open files that the database user will have after login. If the database user gets error messages about running out of file handles, then the database user can increase the number of file handles like in this example up to 63536 (”hard limit”) by running the following command:

ulimit -n 63536

Most shells like Bash provide control over various resources like the maximum allowable number of open file descriptors or the maximum number of processes available to a user. To see all shell limits, run:

ulimit -a

# 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

Each line describes a limit for a user in the form:

[domain] [type] [item] [value]
#
#Where:
# can be:
# - an user name
# - a group name, with @group syntax
# - the wildcard *, for default entry
# - the wildcard %, can be also used with %group syntax,
# for maxlogin limit
# - NOTE: group and wildcard limits are not applied to root.
# To apply a limit to the root user, must be
# the literal username root.
#
# can have the two values:
# - “soft” for enforcing the soft limits
# - “hard” for enforcing hard limits
# - cpu - max CPU time (MIN)
# - nproc - max number of processes
# - core - limits the core file size (KB)

Example:

@student hard nproc 50
@faculty soft nproc 50
SBDavid
Sep 30th, 2009

Controlling Server Resources from denial of service using Xinetd

Controlling Server Resources from denial of service using Xinetd

Another important feature of xinetd is its ability to control the amount of resources which services under its control can utilize.

It does this by way of the following directives:

cps = [number_of_connections] [wait_period] — Dictates the connections allowed to the service per second. This directive accepts only integer values.

instances = [number_of_connections] — Dictates the total number of connections allowed to a service. This directive accepts either an integer value or UNLIMITED.

per_source = [number_of_connections] — Dictates the connections allowed to a service by each host. This directive accepts either an integer value or UNLIMITED.

rlimit_as = [number[K|M]] — Dictates the amount of memory address space the service can occupy in kilobytes or megabytes. This directive accepts either an integer value or UNLIMITED.

rlimit_cpu = [number_of_seconds] — Dictates the amount of time in seconds that a service may occupy the CPU. This directive accepts either an integer value or UNLIMITED.

Using these directives can help prevent any one xinetd service from overwhelming the system, resulting in a denial of service.