Archive for March, 2010

Linux - The actual script (CBQ)

Posted in How To's by Shafkat Shahzad, M.Sc on March 27th, 2010

Welcome to the tutorial guide. The tutorial will provide guidance and instructions on the actual script. The action script works on all kernels. Within the CBQ qdisc a user can place two Stochastic Fairness Queues that make sure that multiple bulk streams don’t drown each other out.
Downstream traffic is policed using a tc filter containing a Token Bucket Filter.
A user can improve on this script by adding bounded to the line that starts with ‘tc class add .. classid 1:20′. If a user lowered the MTU, also lower the allot & avpkt numbers!
#!/bin/bash

# The Ultimate Setup For Your Internet Connection At Home
#
#
# Set the following values to somewhat less than the actual download
# and uplink speed. In kilobits
DOWNLINK=800
UPLINK=220
DEV=ppp0

# clean existing down- and uplink qdiscs, hide errors
tc qdisc del dev $DEV root 2> /dev/null > /dev/null
tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null

###### uplink

# install root CBQ

tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth 10mbit

# shape everything at $UPLINK speed - this prevents huge queues in your
# DSL modem which destroy latency:
# main class

tc class add dev $DEV parent 1: classid 1:1 cbq rate ${UPLINK}kbit \
allot 1500 prio 5 bounded isolated

# high prio class 1:10:

tc class add dev $DEV parent 1:1 classid 1:10 cbq rate ${UPLINK}kbit \
allot 1600 prio 1 avpkt 1000

# bulk and default class 1:20 - gets slightly less traffic,
# and a lower priority:

tc class add dev $DEV parent 1:1 classid 1:20 cbq rate $[9*$UPLINK/10]kbit \
allot 1600 prio 2 avpkt 1000

# both get Stochastic Fairness:
tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10

# start filters
# TOS Minimum Delay (ssh, NOT scp) in 1:10:
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
match ip tos 0×10 0xff flowid 1:10

# ICMP (ip protocol 1) in the interactive class 1:10 so we
# can do measurements & impress our friends:
tc filter add dev $DEV parent 1:0 protocol ip prio 11 u32 \
match ip protocol 1 0xff flowid 1:10

# To speed up downloads while an upload is going on, put ACK packets in
# the interactive class:

tc filter add dev $DEV parent 1: protocol ip prio 12 u32 \
match ip protocol 6 0xff \
match u8 0×05 0×0f at 0 \
match u16 0×0000 0xffc0 at 2 \
match u8 0×10 0xff at 33 \
flowid 1:10

# rest is ‘non-interactive’ ie ‘bulk’ and ends up in 1:20

tc filter add dev $DEV parent 1: protocol ip prio 13 u32 \
match ip dst 0.0.0.0/0 flowid 1:20

########## downlink #############
# slow downloads down to somewhat less than the real speed to prevent
# queuing at our ISP. Tune to see how high you can set it.
# ISPs tend to have *huge* queues to make sure big downloads are fast
#
# attach ingress policer:

tc qdisc add dev $DEV handle ffff: ingress

# filter *everything* to it (0.0.0.0/0), drop everything that’s
# coming in too fast:

tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1
If you want this script to be run by ppp on connect, copy it to /etc/ppp/ip-up.d.
As user should note that if the last two lines give an error, then please update the tc tool to a newer version.
If a user followed advise and guidance as provided in this tutorial guide then he/she has learnt about the actual script.

Bookmark Us
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • MisterWong
  • Netvouz
  • Reddit
  • Slashdot
  • Spurl
  • StumbleUpon
  • Technorati
  • Wists

Linux - The actual script (HTB)

Posted in How To's by Shafkat Shahzad, M.Sc on March 27th, 2010

Welcome to the tutorial guide. The guide will provide a user with guidance and instructions on the actual script.
#!/bin/bash

# The Ultimate Setup For the Internet Connection At Home
#
#
# Set the following values to somewhat less than the actual download
# and uplink speed. In kilobits
DOWNLINK=800
UPLINK=220
DEV=ppp0

# clean existing down- and uplink qdiscs, hide errors
tc qdisc del dev $DEV root 2> /dev/null > /dev/null
tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null

###### uplink

# install root HTB, point default traffic to 1:20:

tc qdisc add dev $DEV root handle 1: htb default 20

# shape everything at $UPLINK speed - this prevents huge queues in the
# DSL modem which destroy latency:

tc class add dev $DEV parent 1: classid 1:1 htb rate ${UPLINK}kbit burst 6k

# high prio class 1:10:

tc class add dev $DEV parent 1:1 classid 1:10 htb rate ${UPLINK}kbit \
burst 6k prio 1

# bulk & default class 1:20 - gets slightly less traffic,
# and a lower priority:

tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[9*$UPLINK/10]kbit \
burst 6k prio 2

# both get Stochastic Fairness:
tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10

# TOS Minimum Delay (ssh, NOT scp) in 1:10:
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
match ip tos 0×10 0xff flowid 1:10

# ICMP (ip protocol 1) in the interactive class 1:10 so we
# can do measurements & impress our friends:
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
match ip protocol 1 0xff flowid 1:10

# To speed up downloads while an upload is going on, put ACK packets in
# the interactive class:

tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \
match ip protocol 6 0xff \
match u8 0×05 0×0f at 0 \
match u16 0×0000 0xffc0 at 2 \
match u8 0×10 0xff at 33 \
flowid 1:10

# rest is ‘non-interactive’ ie ‘bulk’ and ends up in 1:20

########## downlink #############
# slow downloads down to somewhat less than the real speed to prevent
# queuing at the ISP. Tune to see how high a user can set it.
# ISPs tend to have *huge* queues to make sure big downloads are fast
#
# attach ingress policer:

tc qdisc add dev $DEV handle ffff: ingress

# filter *everything* to it (0.0.0.0/0), drop everything that’s
# coming in too fast:

tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1
If the last two lines give an error, then a user can update the tc tool to a newer version.
If you followed the tutorial guide then you would have learnt about the actual script (HTB).

Bookmark Us
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • MisterWong
  • Netvouz
  • Reddit
  • Slashdot
  • Spurl
  • StumbleUpon
  • Technorati
  • Wists

Linux - transparent web-caching using netfilter, iproute2

Posted in How To's by Shafkat Shahzad, M.Sc on March 27th, 2010

Welcome to the tutorial guide. The guide will provide guidance and instructions on transparent we caching using netfilter, iproute2, ipchains and squid.

The regular technique in accomplishing this in Linux is probably with use of ipchains AFTER making sure that the outgoing port 80(web) traffic gets routed through the server running squid.
Please note that there are 3 common methods to make sure “outgoing” port 80 traffic gets routed to the server running squid and 4th one is being introduced here.
Making the gateway router do it.
If a user can tell his/her gateway router to match packets that has outgoing destination port of 80 to be sent to the IP address of squid server.
BUT
This would put additional load on the router and some commercial routers might not even support this.
Using a Layer 4 switch.
Layer 4 switches can handle this without any problem.
BUT
The cost for this equipment is usually very high. Typical layer 4 switch would normally cost more than a typical router+good linux server.
Using cache server as network’s gateway.
A user can force all traffic through cache server.
but
This is quite risky because Squid does utilize lots of CPU power which might result in slower over-all network performance or the server itself might crash and no one on the network will be able to access the Internet if that occurs.
Linux+NetFilter router.
By using NetFilter another technique can be implemented which is using NetFilter for “mark”ing the packets with destination port 80 and using iproute2 to route the “mark”ed packets to the Squid server.
|—————-|
| Implementation |
|—————-|

Addresses used
10.0.0.1 naret (NetFilter server)
10.0.0.2 silom (Squid server)
10.0.0.3 donmuang (Router connected to the Internet)
10.0.0.4 kaosarn (other server on network)
10.0.0.5 RAS
10.0.0.0/24 main network
10.0.0.0/19 total network

|—————|
|Network diagram|
|—————|

Internet
|
donmuang
|
————hub/switch———-
| | | |
naret silom kaosarn RAS etc.

First, make all traffic pass through naret by making sure it is the default gateway except for silom. Silom’s default gateway has to be donmuang (10.0.0.3) or this would create web traffic loop.
(all servers on my network had 10.0.0.1 as the default gateway which was the former IP address of donmuang router so what I did was changed the IP address of donmuang to 10.0.0.3 and gave naret ip address of 10.0.0.1)
Silom
—–
-setup squid and ipchains

Setup Squid server on silom, make sure it does support transparent caching/proxying, the default port is usually 3128, so all traffic for port 80 has to be redirected to port 3128 locally. This can be done by using ipchains with the following:
silom# ipchains -N allow1
silom# ipchains -A allow1 -p TCP -s 10.0.0.0/19 -d 0/0 80 -j REDIRECT 3128
silom# ipchains -I input -j allow1

Or, in netfilter lingo:
silom# iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 80 -j REDIRECT –to-port 3128

Please ensure that ip forwarding is enabled on this server and the default gateway for this server is donmuang router (NOT naret).
Naret
—–
-setup iptables and iproute2
-disable icmp REDIRECT messages (if needed)

1. “Mark” packets of destination port 80 with value 2
2. naret# iptables -A PREROUTING -i eth0 -t mangle -p tcp –dport 80 \
3. -j MARK –set-mark 2
4. Setup iproute2 so it will route packets with “mark” 2 to silom
5. naret# echo 202 www.out >> /etc/iproute2/rt_tables
6. naret# ip rule add fwmark 2 table www.out
7. naret# ip route add default via 10.0.0.2 dev eth0 table www.out
8. naret# ip route flush cache

If donmuang and naret is on the same subnet then naret should not send out icmp REDIRECT messages. In this case it is, so icmp REDIRECTs has to be disabled by:
naret# echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
naret# echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects
naret# echo 0 > /proc/sys/net/ipv4/conf/eth0/send_redirects

The setup is complete, check the configuration
On naret:

naret# iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
MARK tcp — anywhere anywhere tcp dpt:www MARK set 0×2

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

naret# ip rule ls
0: from all lookup local
32765: from all fwmark 2 lookup www.out
32766: from all lookup main
32767: from all lookup default

naret# ip route list table www.out
default via 203.114.224.8 dev eth0

naret# ip route
10.0.0.1 dev eth0 scope link
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.1
127.0.0.0/8 dev lo scope link
default via 10.0.0.3 dev eth0

(make sure silom belongs to one of the above lines, in this case
it’s the line with 10.0.0.0/24)

|——|
|-DONE-|
|——|

If you followed the tutorial guide then you would have learnt about transparent web-caching using netfilter, iproute2, ipchains and squid

Bookmark Us
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • MisterWong
  • Netvouz
  • Reddit
  • Slashdot
  • Spurl
  • StumbleUpon
  • Technorati
  • Wists

Linux - prioritising interactive traffic

Posted in How To's by Shafkat Shahzad, M.Sc on March 20th, 2010

Welcome to the tutorial guide. The tutorial will provide a user with guidance and instructions on prioritising interactive traffic.

If there is a lot of data coming down or up and user is trying to carry out some through telnet or ssh, this may not go too well. Other packets are blocking the keystrokes. Linux can provide a user with an opportunity so that the user can sneak past the bulk traffic with the interactive packet.
As before, we need to handle traffic going both ways. Evidently, this works best if there are Linux boxes on both ends of the link, although other UNIX’s are able to do this.
The standard pfifo_fast scheduler has 3 different ‘bands’. Traffic in band 0 is transmitted first, after which traffic in band 1 and 2 gets considered. It is vital that our interactive traffic be in band 0!
The most common use is to set telnet & ftp control connections to “Minimum Delay” and FTP data to “Maximum Throughput”. This would be done as follows, on the upstream router:
# iptables -A PREROUTING -t mangle -p tcp –sport telnet \
-j TOS –set-tos Minimize-Delay
# iptables -A PREROUTING -t mangle -p tcp –sport ftp \
-j TOS –set-tos Minimize-Delay
# iptables -A PREROUTING -t mangle -p tcp –sport ftp-data \
-j TOS –set-tos Maximize-Throughput
Now, this only works for data going from the telnet foreign host to the local computer. The other way around appears to be done i.e., telnet, ssh & friends all set the TOS field on outgoing packets automatically.
If a users application does not do this, then a user should do this with netfilter. On the local box:
# iptables -A OUTPUT -t mangle -p tcp –dport telnet \
-j TOS –set-tos Minimize-Delay
# iptables -A OUTPUT -t mangle -p tcp –dport ftp \
-j TOS –set-tos Minimize-Delay
# iptables -A OUTPUT -t mangle -p tcp –dport ftp-data \
-j TOS –set-tos Maximize-Throughput

If you followed this tutorial guide then you would have learnt about prioritising interactive traffic.

Bookmark Us
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • MisterWong
  • Netvouz
  • Reddit
  • Slashdot
  • Spurl
  • StumbleUpon
  • Technorati
  • Wists

Linux - Rate limit ICMP to prevent dDoS

Posted in How To's by Shafkat Shahzad, M.Sc on March 20th, 2010

Welcome to the tutorial guide. The tutorial guide will provide a user with guidance and instructions on rate limit ICMP to prevent dDoS. Pleae note that recently, distributed denial of service attacks have become a major nuisance on the Internet. By properly filtering and rate limiting of the network, a user can prevent becoming a casualty and the cause of the service attacks.
A user should filter his/her networks so that he/she does not allow non-local IP source addressed packets to leave his/her network. This stops people from anonymously sending junk to the Internet.
Please note the ASCIIgram again:
[The Internet] —— [Linux router] — [Office+ISP]
eth1 eth0

A user has to set up the prerequisite parts:
# tc qdisc add dev eth0 root handle 10: cbq bandwidth 10Mbit avpkt 1000
# tc class add dev eth0 parent 10:0 classid 10:1 cbq bandwidth 10Mbit rate \
10Mbit allot 1514 prio 5 maxburst 20 avpkt 1000
If a user has 100Mbit, or more, interfaces, then a user can adjust these numbers. After that a user has to determine how much ICMP traffic that he/she wants to allow. A user can perform measurements with tcpdump, by having it write to a file for a while, and seeing how much ICMP passes his/her network.
In order to setup a class please view following:
# tc class add dev eth0 parent 10:1 classid 10:100 cbq bandwidth 10Mbit rate \
100Kbit allot 1514 weight 800Kbit prio 5 maxburst 20 avpkt 250 \
bounded
This limits at 100Kbit. Now a user needs a filter to assign ICMP traffic to this class:
# tc filter add dev eth0 parent 10:0 protocol ip prio 100 u32 match ip
protocol 1 0xFF flowid 10:100

If you followed this tutorial guide then you would have learnt about the rate limit ICMP to prevent dDoS.

Bookmark Us
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • MisterWong
  • Netvouz
  • Reddit
  • Slashdot
  • Spurl
  • StumbleUpon
  • Technorati
  • Wists

Linux - Protecting host from SYN floods

Posted in How To's by Shafkat Shahzad, M.Sc on March 20th, 2010

Welcome to the tutorial guide. The guide will provide a user with guidance and instructions on protecting his/her host from SYN floods.
If a user wants a latest version of the iproute2 tools to get this to work with 2.4.0, then please follow:.
#! /bin/sh -x
#
# sample script on using the ingress capabilities
# this script shows how one can rate limit incoming SYNs
# Useful for TCP-SYN attack protection. A user can use
# IPchains to have more powerful additions to the SYN (eg
# in addition the subnet)
#
#path to various utilities;
#change to reflect yours.
#
TC=/sbin/tc
IP=/sbin/ip
IPTABLES=/sbin/iptables
INDEV=eth2
#
# tag all incoming SYN packets through $INDEV as mark value 1
############################################################
$iptables -A PREROUTING -i $INDEV -t mangle -p tcp –syn \
-j MARK –set-mark 1
############################################################
#
# install the ingress qdisc on the ingress interface
############################################################
$TC qdisc add dev $INDEV handle ffff: ingress
############################################################

#
#
# SYN packets are 40 bytes (320 bits) so three SYNs equals
# 960 bits (approximately 1kbit); so we rate limit below
# the incoming SYNs to 3/sec (not very useful really; but
#serves to show the point - JHS
############################################################
$TC filter add dev $INDEV parent ffff: protocol ip prio 50 handle 1 fw \
police rate 1kbit burst 40 mtu 9k drop flowid :1
############################################################

#
echo “—- qdisc parameters Ingress ———-”
$TC qdisc ls dev $INDEV
echo “—- Class parameters Ingress ———-”
$TC class ls dev $INDEV
echo “—- filter parameters Ingress ———-”
$TC filter ls dev $INDEV parent ffff:

#deleting the ingress qdisc
#$TC qdisc del $INDEV ingress

If a user followed advise and guidcance as provided in this tutorial guide then he/she would have learnt about protecting host from SYN floods

Bookmark Us
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • MisterWong
  • Netvouz
  • Reddit
  • Slashdot
  • Spurl
  • StumbleUpon
  • Technorati
  • Wists

Linux - routing settings

Posted in How To's by Shafkat Shahzad, M.Sc on March 20th, 2010

Welcome to the tutorial guide. The tutorial will provide a user with guidance and instructions on routing settings.

/proc/sys/net/ipv4/route/error_burst and /proc/sys/net/ipv4/route/error_cost
This parameters are used to limit the warning messages written to the kernel log from the routing code. The higher the error_cost factor is, the fewer messages will be written. Error_burst controls when messages will be dropped. The default settings limit warning messages to one every five seconds.

/proc/sys/net/ipv4/route/flush
Writing to this file results in a flush of the routing cache.
/proc/sys/net/ipv4/route/gc_elasticity
Values to control the frequency and behavior of the garbage collection algorithm for the routing cache. This can be important for when doing fail over. At least gc_timeout seconds will elapse before Linux will skip to another route because the previous one has died. By default set to 300
/proc/sys/net/ipv4/route/gc_interval
/proc/sys/net/ipv4/route/gc_elasticity.
/proc/sys/net/ipv4/route/gc_min_interval
/proc/sys/net/ipv4/route/gc_elasticity.
/proc/sys/net/ipv4/route/gc_thresh
/proc/sys/net/ipv4/route/gc_elasticity.
/proc/sys/net/ipv4/route/gc_timeout
/proc/sys/net/ipv4/route/gc_elasticity.
/proc/sys/net/ipv4/route/max_delay
Maximum delay for flushing the routing cache.
/proc/sys/net/ipv4/route/max_size
Maximum size of the routing cache. Old entries will be purged once the cache reached has this size.
/proc/sys/net/ipv4/route/min_delay
Minimum delay for flushing the routing cache.

/proc/sys/net/ipv4/route/redirect_load
Factors which determine if more ICMP redirects should be sent to a specific host. No redirects will be sent once the load limit or the maximum number of redirects has been reached.
/proc/sys/net/ipv4/route/redirect_number
/proc/sys/net/ipv4/route/redirect_load.
/proc/sys/net/ipv4/route/redirect_silence
Timeout for redirects. After this period redirects will be sent again, even if this has been stopped, because the load or number limit has been reached.

If you followed the tutorial guide then you would have learnt about routing settings.

Bookmark Us
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • MisterWong
  • Netvouz
  • Reddit
  • Slashdot
  • Spurl
  • StumbleUpon
  • Technorati
  • Wists

Linux - Neighbor policy

Posted in How To's by Shafkat Shahzad, M.Sc on March 20th, 2010

Welcome to the tutorial guide. The tutorial guide will provide a user with guidance and instructions on neighhbor policy.

Dev can either stand for a real interface, or for ‘all’ or ‘default’. Default also changes settings for interfaces yet to be created.
/proc/sys/net/ipv4/neigh/DEV/anycast_delay
Maximum for random delay of answers to neighbor solicitation messages in jiffies (1/100 sec). Not yet implemented (Linux does not have anycast support yet).
/proc/sys/net/ipv4/neigh/DEV/app_solicit
Determines the number of requests to send to the user level ARP daemon. Use 0 to turn off.
/proc/sys/net/ipv4/neigh/DEV/base_reachable_time
A base value used for computing the random reachable time value as specified in RFC2461.
/proc/sys/net/ipv4/neigh/DEV/delay_first_probe_time
Delay for the first time probe if the neighbor is reachable.
/proc/sys/net/ipv4/neigh/DEV/gc_stale_time
Determines how often to check for stale ARP entries. After an ARP entry is stale it will be resolved again (which is useful when an IP address migrates to another machine). When ucast_solicit is greater than 0 it first tries to send an ARP packet directly to the known host When that fails and mcast_solicit is greater than 0, an ARP request is broadcast.
/proc/sys/net/ipv4/neigh/DEV/locktime
An ARP/neighbor entry is only replaced with a new one if the old is at least locktime old. This prevents ARP cache thrashing.
/proc/sys/net/ipv4/neigh/DEV/mcast_solicit
Maximum number of retries for multicast solicitation.
/proc/sys/net/ipv4/neigh/DEV/proxy_delay
Maximum time (real time is random [0..proxytime]) before answering to an ARP request for which we have an proxy ARP entry. In some cases, this is used to prevent network flooding.
/proc/sys/net/ipv4/neigh/DEV/proxy_qlen
Maximum queue length of the delayed proxy arp timer.
/proc/sys/net/ipv4/neigh/DEV/retrans_time
The time, expressed in jiffies (1/100 sec), between retransmitted Neighbor Solicitation messages. Used for address resolution and to determine if a neighbor is unreachable.
/proc/sys/net/ipv4/neigh/DEV/ucast_solicit
Maximum number of retries for unicast solicitation.
/proc/sys/net/ipv4/neigh/DEV/unres_qlen
Maximum queue length for a pending arp request - the number of packets which are accepted from other layers while the ARP address is still resolved.

If you followed the tutorial guide then you would have learnt about neighbour policy.

Bookmark Us
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • MisterWong
  • Netvouz
  • Reddit
  • Slashdot
  • Spurl
  • StumbleUpon
  • Technorati
  • Wists

Linux - Generic ipv4

Posted in How To's by Shafkat Shahzad, M.Sc on March 17th, 2010

Welcome to the tutorial guide. The guide will provide a user with guidance and instructions on generic ipv4. Please note that the kernel has an internal clock which runs at HZ ticks per second. On Intel, HZ is mostly 100. So setting a *_rate file to, say 50, would allow for 2 packets per second.

/proc/sys/net/ipv4/icmp_destunreach_rate
If the kernel decides that it can’t deliver a packet, it will drop it, and send the source of the packet an ICMP notice to this effect.
/proc/sys/net/ipv4/icmp_echo_ignore_all
Don’t act on echo packets at all. Please don’t set this by default, but if a user is used as a relay in a DoS attack, it may be useful.
/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts [Useful]
If a user pings the broadcast address of a network, all hosts are supposed to respond. This makes for a dandy denial-of-service tool. Set this to 1 to ignore these broadcast messages.
/proc/sys/net/ipv4/icmp_echoreply_rate
The rate at which echo replies are sent to any one destination.
/proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
Set this to ignore ICMP errors caused by hosts in the network reacting badly to frames sent to what they perceive to be the broadcast address.
/proc/sys/net/ipv4/icmp_paramprob_rate
A relatively unknown ICMP message, which is sent in response to incorrect packets with broken IP or TCP headers. With this file a user can control the rate at which it is sent.
/proc/sys/net/ipv4/icmp_timeexceed_rate
This is the famous cause of the ‘Solaris middle star’ in traceroutes. Limits the rate of ICMP Time Exceeded messages sent.
/proc/sys/net/ipv4/igmp_max_memberships
Maximum number of listening igmp (multicast) sockets on the host. FIXME: Is this true?
/proc/sys/net/ipv4/inet_peer_gc_maxtime
FIXME: Add a little explanation about the inet peer storage? Miximum interval between garbage collection passes. This interval is in effect under low (or absent) memory pressure on the pool. Measured in jiffies.
/proc/sys/net/ipv4/inet_peer_gc_mintime
Minimum interval between garbage collection passes. This interval is in effect under high memory pressure on the pool. Measured in jiffies.
/proc/sys/net/ipv4/inet_peer_maxttl
Maximum time-to-live of entries. Unused entries will expire after this period of time if there is no memory pressure on the pool (i.e. when the number of entries in the pool is very small). Measured in jiffies.
/proc/sys/net/ipv4/inet_peer_minttl
Minimum time-to-live of entries. Should be enough to cover fragment time-to-live on the reassembling side. This minimum time-to-live is guaranteed if the pool size is less than inet_peer_threshold. Measured in jiffies.
/proc/sys/net/ipv4/inet_peer_threshold
The approximate size of the INET peer storage. Starting from this threshold entries will be thrown aggressively. This threshold also determines entries’ time-to-live and time intervals between garbage collection passes. More entries, less time-to-live, less GC interval.
/proc/sys/net/ipv4/ip_autoconfig
This file contains the number one if the host received its IP configuration by RARP, BOOTP, DHCP or a similar mechanism. Otherwise it is zero.
/proc/sys/net/ipv4/ip_default_ttl
Time To Live of packets. Set to a safe 64.
/proc/sys/net/ipv4/ip_dynaddr
A user can set this if he/she uses dial-on-demand with a dynamic interface address. If the demand interface comes up, any local TCP sockets which haven’t seen replies will be rebound to have the right address. This solves the problem that the connection that brings up the interface does not work, but the second try does.
/proc/sys/net/ipv4/ip_forward
If the kernel should attempt to forward packets. Off by default.
/proc/sys/net/ipv4/ip_local_port_range
Range of local ports for outgoing connections. Actually quite small by default, 1024 to 4999.
/proc/sys/net/ipv4/ip_no_pmtu_disc
A user can set this if he/she wants to disable Path MTU discovery. This is a technique to determine the largest Maximum Transfer Unit possible on the path.
/proc/sys/net/ipv4/ipfrag_high_thresh
Maximum memory used to reassemble IP fragments. When ipfrag_high_thresh bytes of memory is allocated for this purpose, the fragment handler will toss packets until ipfrag_low_thresh is reached.
/proc/sys/net/ipv4/ip_nonlocal_bind
A user can set this if he/she wants his/her applications to be able to bind to an address which doesn’t belong to a device on the system. This can be useful when a users’ machine is on a non-permanent (or even dynamic) link, so the services are able to start up and bind to a specific address when the link is down.
/proc/sys/net/ipv4/ipfrag_low_thresh
Minimum memory used to reassemble IP fragments
/proc/sys/net/ipv4/ipfrag_time
Time in seconds to keep an IP fragment in memory.
/proc/sys/net/ipv4/tcp_abort_on_overflow
A boolean flag controlling the behaviour under lots of incoming connections. When enabled, this causes the kernel to actively send RST packets when a service is overloaded.
/proc/sys/net/ipv4/tcp_fin_timeout
Time to hold socket in state FIN-WAIT-2, if it was closed by a user. Peer can be broken and never close its side, or even died unexpectedly. Default value is 60sec. Usual value used in 2.2 was 180 seconds, a user may restore it, but remember that if his/her machine is even underloaded WEB server, he/she will risk to overflow memory with kilotons of dead sockets, FIN-WAIT-2 sockets are less dangerous than FIN-WAIT-1, because they eat maximum 1.5K of memory, but they tend to live longer. Cf. tcp_max_orphans.
/proc/sys/net/ipv4/tcp_keepalive_time
How often TCP sends out keepalive messages when keepalive is enabled. Default: 2hours.
/proc/sys/net/ipv4/tcp_keepalive_intvl
How frequent probes are retransmitted, when a probe isn’t acknowledged. Default: 75 seconds.
/proc/sys/net/ipv4/tcp_keepalive_probes
How many keepalive probes TCP will send, until it decides that the connection is broken. Default value: 9. Multiplied with tcp_keepalive_intvl, this gives the time a link can be non-responsive after a keepalive has been sent.
/proc/sys/net/ipv4/tcp_max_orphans
Maximal number of TCP sockets not attached to any user file handle, held by system. If this number is exceeded orphaned connections are reset immediately and warning is printed. This limit exists only to prevent simple DoS attacks. A user should not rely on this or lower the limit artificially, but rather increase it, if network conditions require more than default value, and tune network services to linger and kill such states more aggressively.
/proc/sys/net/ipv4/tcp_orphan_retries
How may times to retry before killing TCP connection, closed by the user. Default value 7 corresponds to 50sec-16min depending on RTO. If a users machine is a loaded WEB server, a user should think about lowering this value, such sockets may consume significant resources. Cf. tcp_max_orphans.
/proc/sys/net/ipv4/tcp_max_syn_backlog
Maximal number of remembered connection requests, which still did not receive an acknowledgment from connecting client. Default value is 1024 for systems with more than 128Mb of memory, and 128 for low memory machines. If server suffers of overload, try to increase this number. Please note that if P make it greater than 1024, it would be better to change TCP_SYNQ_HSIZE in include/net/tcp.h to keep TCP_SYNQ_HSIZE*16<=tcp_max_syn_backlog and to recompile kernel.
/proc/sys/net/ipv4/tcp_max_tw_buckets
Maximal number of timewait sockets held by system simultaneously. If this number is exceeded time-wait socket is immediately destroyed and warning is printed. This limit exists only to prevent simple DoS attacks, a user_must_ not lower the limit artificially, but rather increase it (probably, after increasing installed memory), if network conditions require more than default value.
/proc/sys/net/ipv4/tcp_retrans_collapse
Bug-to-bug compatibility with some broken printers. On retransmit try to send bigger packets to work around bugs in certain TCP stacks.
/proc/sys/net/ipv4/tcp_retries1
How many times to retry before deciding that something is wrong and it is necessary to report this suspicion to network layer. Minimal RFC value is 3, it is default, which corresponds to 3sec-8min depending on RTO.
/proc/sys/net/ipv4/tcp_retries2
How may times to retry before killing alive TCP connection. RFC 1122 says that the limit should be longer than 100 sec. It is too small number. Default value 15 corresponds to 13-30min depending on RTO.
/proc/sys/net/ipv4/tcp_rfc1337
This boolean enables a fix for ‘time-wait assassination hazards in tcp’, described in RFC 1337. If enabled, this causes the kernel to drop RST packets for sockets in the time-wait state. Default: 0
/proc/sys/net/ipv4/tcp_sack
Use Selective ACK which can be used to signify that specific packets are missing - therefore helping fast recovery.
/proc/sys/net/ipv4/tcp_stdurg
Use the Host requirements interpretation of the TCP urg pointer field. Most hosts use the older BSD interpretation, so if a user turns this on Linux might not communicate correctly with them. Default: FALSE
/proc/sys/net/ipv4/tcp_syn_retries
Number of SYN packets the kernel will send before giving up on the new connection.
/proc/sys/net/ipv4/tcp_synack_retries
To open the other side of the connection, the kernel sends a SYN with a piggybacked ACK on it, to acknowledge the earlier received SYN. This is part 2 of the threeway handshake. This setting determines the number of SYN+ACK packets sent before the kernel gives up on the connection.
/proc/sys/net/ipv4/tcp_timestamps
Timestamps are used, amongst other things, to protect against wrapping sequence numbers. A 1 gigabit link might conceivably re-encounter a previous sequence number with an out-of-line value, because it was of a previous generation. The timestamp will let it recognize this ‘ancient packet’.
/proc/sys/net/ipv4/tcp_tw_recycle
Enable fast recycling TIME-WAIT sockets. Default value is 1. It should not be changed without advice/request of technical experts.
/proc/sys/net/ipv4/tcp_window_scaling
TCP/IP normally allows windows up to 65535 bytes big. For really fast networks, this may not be enough. The window scaling options allows for almost gigabyte windows, which is good for high bandwidth*delay products.

If you followed this tutorial guide then you would have learnt about generic ipv4

Bookmark Us
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • MisterWong
  • Netvouz
  • Reddit
  • Slashdot
  • Spurl
  • StumbleUpon
  • Technorati
  • Wists

Linux - ipv4 per device settings

Posted in How To's by Shafkat Shahzad, M.Sc on March 13th, 2010

Welcome to the tutorial guide. The guide will provide a user with guidance and instructions on ipv4 per device settings.

Please note that DEV can either stand for a real interface, or for ‘all’ or ‘default’. Default also changes settings for interfaces.
/proc/sys/net/ipv4/conf/DEV/accept_redirects
If a router decides that a user is using it for a wrong purpose (i.e., it needs to resend the users packet on the same interface), it will send us a ICMP Redirect. As this is a security risk so it is worth to turn it off, or use secure redirects.
/proc/sys/net/ipv4/conf/DEV/accept_source_route
This is not used that much and if a user used to be able to give a packet a list of IP addresses it should visit on its way. Linux can be made to honor this IP option.
/proc/sys/net/ipv4/conf/DEV/bootp_relay
Accept packets with source address 0.b.c.d with destinations not to this host as local ones. It is supposed that a BOOTP relay daemon will catch and forward such packets.
The default is 0, since this feature is not implemented yet (kernel version 2.2.12).
/proc/sys/net/ipv4/conf/DEV/forwarding
Enable or disable IP forwarding on this interface.

/proc/sys/net/ipv4/conf/DEV/mc_forwarding
If a user wants to do multicast forwarding on this interface
/proc/sys/net/ipv4/conf/DEV/proxy_arp
If a user sets this to 1, this interface will respond to ARP requests for addresses the kernel has routes to. It is useful if a user wants to build ip pseudo bridges. A user should be aware that the the netmasks are very correct before enabling this. Also the user should be aware that the rp_filter, operates on ARP queries!
/proc/sys/net/ipv4/conf/DEV/secure_redirects
Accept ICMP redirect messages only for gateways, listed in default gateway list. Enabled by default.
/proc/sys/net/ipv4/conf/DEV/send_redirects
If a user sends the above mentioned redirects.
/proc/sys/net/ipv4/conf/DEV/shared_media
If it is not set the kernel does not assume that different subnets on this device can communicate directly. Default setting is ‘yes’.
/proc/sys/net/ipv4/conf/DEV/tag

If you followed advise and guidance as provided in this tutorial guide then you would have learnt about ipv4 per device settings.

Bookmark Us
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • MisterWong
  • Netvouz
  • Reddit
  • Slashdot
  • Spurl
  • StumbleUpon
  • Technorati
  • Wists

« Previous entries