How to perform the Tuning of a Linux Box
Do you like this story?
So what you are supposed to do whe the word "tuning of linux" comes to your nerves. Well, lets explore this one and start by opening the /etc/sysctl.conf file, which stores the kernel parameters. Here is the example of this file.
# Kernel sysctl configuration file for Red Hat Linux. # For binary values, 0 is disabled, 1 is enabled. See sysctl(8) for # more details. # Controls IP packet forwarding. net.ipv4.ip_forward = 0 # Controls source route verification. net.ipv4.conf.default.rp_fliter = 1 kernel.sysrq = 1 kernel.core_uses_pid = 1 #net.ipv4.tcp_ecn = 0 kernel.grsecurity.fifo_restrictions = 1 kernel.grsecurity.linking_restrictions = 1 # Audit some operations. kernel.grsecurity.audit_mount=1 kernel.grsecurity.signal_logging=1 #kernel.grsecurity.suid_logging=1 kernel.grsecurity.timechange_logging=l kernel.grsecurity.forkfail_logging=1 kernel.grsecurity.coredump = 1 # Lock all security options. #kernel.grsecurity.grsec_lock = 1
I'll consider the function of the parameters saved in the file, using as an example the net.ipv4.tcp_ecn parameter. This is a path, relative to the /proc/sys directory, to the tcp_ecn file, namely: /proc/sys/net/ipv4/tcp_ecn. Execute the following command to view the contents of the file:
cat /proc/sys/net/ipv4/tcp_ecn
The system will display 0 or 1, which is the value of this parameter.
You can change the value manually, but it's more convenient to do this by executing the following command:
sysctl -w paramater_name = new_value
The same command can be used to view the value of the kernel parameter:
sysctl parameter_name
For example, the value of the net.ipv4.tcp_ecn parameter, which is stored in the /proc/sys/net/ipv4/tcp_ecn file, is displayed as follows:
sysctl net.ipv4.tcp_ecn
The values of most parameters are Boolean, meaning they can be either 0 (disabled) or 1 (enabled).
The following are the parameters that should be changed. If they are not in the sysctl.conf file, they should be added to it.
- net.ipv4.icmp_echo_ignore_broadcasts — When this parameter is enabled, the system ignores broadcast ICMP echo packets.
- net.ipv4.icmp_echo_ignore_all — When this parameter is enabled, all ICMP echo packets are ignored. You can use this parameter if you don't want to fool around with the firewall. Prohibiting echo-request packets reduces the traffic, albeit not by much, and makes ineffective any attacks based on using ping packets.
- net.ipv4.conf.*.accept_redirects — This parameter controls accepting router-redirection messages.
The asterisk character is a wild card and stands for any directory name. There can be several subdirectories in the net/ipv4/conf directory, one for each network interface. There should be at least four such subdirectories in your system:
- all — Contains configuration files for all interfaces
- default — Holds the default values
- eth0 — Holds configuration files for the first network card
- lo — Holds configuration files for the loopback interface
The asterisk indicates that the parameter must be set for all interfaces whose parameter files are stored in the subdirectories of the net/ipv4/conf directory. In most cases, the all directory can be substituted for the asterisk, but sometimes all existing subdirectories have to be specified.
- net.ipv4.conf.*.secure_redirects — When set, this enables ICMP redirect messages to be accepted only for gateways listed in the default gateway list. It is advisable to enable this parameter only if there is more than one router in your network; otherwise, it should be disabled.
- net.ipv4.conf.*.send_redirects — This parameter allows a computer acting as a router to send ICMP redirect messages to other hosts. If there is more than one router in the network, it is advisable to enable this parameter, so that you can distribute the workload among the routers and not try to route all traffic through the main gateway.
- net.ipv4.conf.*.accept_source_route — This parameter controls whether source-routed packages should be accepted or declined. I already mentioned that such packets can be used to bypass your firewall; thus, you should disable this parameter.
- net.ip_always_defrag — When set, all incoming packets are defragmented. I already explained how the firewall can be bypassed using fragmented packets. It just happens that the firewall checks only the first fragment of the packet and considers the rest of the fragments allowed if the first one passes the check. When this parameter is set, all incoming packets are defragmented, thus making bypassing the firewall using this method impossible.
- net.ipv4.ipfrag_low_thresh — This specifies the minimum amount of memory allocated to reassemble fragmented packets. The higher this value, the fewer memory-allocation manipulations necessary. The default value is 196608. Setting this parameter too high will cause extra memory to be allocated and may result in the server running out of resources for processing data. It is advisable to leave the default value.
- net.ipv4.ipfrag_high_thresh — This specifies the maximum amount of memory allocated to reassemble fragmented IP packets. The default value is 262144. If this value is exceeded, the operating system starts tossing out incoming fragmented packets. In this way, a server can be flooded with trashy fragmented messages causing it to no longer react to fragmented packets.
- net.ipv4.ipfrag_time — This indicates the time in seconds to keep an IP packet fragment in memory. The default value is 30 seconds. This is too much, because during this time hackers can flood the entire cache. In case of an attack on the system, the value should be lowered to 20 or even 10 seconds.
- net.ipv4.tcp_syncookies — This controls whether to send out SYN cookies when the SYN queue of a socket overflows. It is advisable to enable this parameter to ward off SYN flood attacks.
These are some of the main kernel parameters. There are too many of them for each to be considered in this book. I advise you to consult the pertinent documentation for information on parameters not included in the preceding overview.
Subscribe to:
Post Comments (Atom)
0 Responses to “How to perform the Tuning of a Linux Box”
Post a Comment