3.4. ICMP Variables
These are the variables available in ipsysctl to change the behaviour for ICMP traffic. These are rather simple and should not pose any real problem to understand as some of the TCP variables may. They are generally very simple and mainly tell the kernel how to react on different ICMP types and if they are to be limited etcetera.
3.4.1. icmp_echo_ignore_all
If this value is set to 1, in other words on or true, the kernel chooses to totally ignore all ICMP Echo requests. This variable takes a boolean value and is per default set to false, or off. If this is variable is turned on, you and others will be unable to ping the machine in question which is generally a bad thing. Of course, everyone has different opinions about this, some say it is good because people will be unable to ping you and hence know you are there, some say it is bad because you want people to know you are available on the internet. A lot of tools and applications rely upon ICMP Echo requests, some good, some bad as always.
3.4.2. icmp_echo_ignore_broadcasts
This variable works precisely the same as icmp_echo_ignore_all except that it will only ignore those ICMP messages sent to broadcast or multicast addresses. It should be quite obvious why this is good, it would among other things stop this specific host from being part of smurf attacks and likely problems. Broadcast pings are generally bad unless you are using this to find out how many hosts on your network(s) are up or not.
The icmp_echo_ignore_broadcasts variable takes a boolean value and is per default turned off. If you want to turn this value on, you should do so since there is relatively few bad sides to not replying to broadcast pings.
3.4.3. icmp_ignore_bogus_error_responses
There are some routers on the internet and in other places that ignore the standards drawn up in RFC 1122 and sends out bogus responses to broadcast frames. Normally, these violations are logged via the kernel logging facilities, but if we do not want to see these error messages in our logs we may turn this variable on, which will lead to all such error messages being ignored totally. If you live close to such a router, you will save much harddrive space in not logging these messages.
This variable takes a boolean value as you may understand, and is per default set to 0 or off. If you need or want this option and want to get rid of some annoying error messages in your logs, you may turn this on.
3.4.4. icmp_ratelimit
icmp_ratelimit is the maximum rate at which the kernel generates icmp messages of the types specified by icmp_ratemask (see icmp_ratemask). The value is the number of jiffies the kernel has to wait between sending two such messages. Therefore zero means no limit. Typically 1 jiffy = 1/100 sec, so a value of 1 means no more than 100/sec, a value of 100 means no more than 1/sec.
Per default, this variable is set to 100, which means 1 ICMP packet may be sent in 100 jiffies. If we set it to 1, we allow 100 ICMP packets per second, and 0 means unlimited ICMP sendings.
3.4.5. icmp_ratemask
The icmp_ratemask variable sets the mask of which ICMP types should be ratelimited with the icmp_ratelimit variable. The types are put together in the mask by setting specific bits in this variable.
icmp_ratemask is the sum of 2^n for each icmp type you wish to ratelimit, and where n is each ICMP type as specified in the header files of the kernel. This ensures that each bit has a specific meaning. All of the different ICMP names and their corresponding values are available in the include file netinet/ip_icmp.h (generally /usr/include/netinet/ip_icmp.h on most systems). For more information about the different ICMP values and their meaning, see RFC 792 - Internet Control Message Protocol. This would be the complete mathematical formula for the expression:
For all ICMP types n to be rate limited.
For example, if you want to include the ICMP Destination unreachable type in the ratemask, we would notice that this has the value 3 in the header files. To do the conversion then, we would calculate 2^3, which turns out to be 8. Finally, you would or this to the bitmask that you already have. So, if your mask already is 6160, you would go 6160+8 which should do the trick. To or two values means to only add the new entry, in case it was not added previously, in a binary way.
 | Make absolutely sure that the ratemask does not contain the bitmask that you want to add. If you fail to notice such a problem, your ratemask will become totally wrong. If you have 256 set already, and then try to set 256 again according to this description, you will wind up with ICMP Echo Request unset, and ICMP type 9 set. ICMP type 9 does not exist. |
The default value of this variable is 6168, which means that ICMP Destination Unreachable, ICMP Source Quench, ICMP Time Exceeded and ICMP Parameter Problem is in the mask. ICMP Destination Unreachable equals 3, ICMP Source Quench equals 4, ICMP Time Exceeded equals 11 and ICMP Parameter Problem equals 12. Hence, the default value is calculated like this:
 | An attacker could cause a correctly operating host or router to flood a victim with ICMP replies by sending it packets that generate replies back to the (forged) source address of the victim. It is important in some cases to send such replies, but hardly ever important to generate them at a very high rate. |
 | There is a small program to output the proper ICMP ratemask called ratemask, which is available at http://www.frozentux.net. It may be of some help when creating icmp_ratemasks, or if you want to find out what the current value means. |
3.4.6. igmp_max_memberships
This variable changes the maximum amounts of multicast groups we may subscribe to per socket. This is per default set to 20 and may be changed as needed.
Fixme: NEED MORE DETAILS!!!