UNIX System Security Checklist
The below checklist is a recommendation for a generalized secure UNIX system configuration. It is intended to provide technical guidance to the user, not a specification that must be adhered to in all circumstances (some recommendations may not be applicable or practical in some situations). As with all IT systems, it is ultimately the responsibility of the system owner/user to make sure that the system is managed and operated in a secure manner.
General Instructions
This checklist is intended for the system administrator of one or more UNIX systems. Where possible automated tools have been identified that will greatly simplify the execution of this checklist. Tools include:
- SARA: Open Source (pending) network assessment tools for security auditing
- TARA: Corporate derived security system auditing tool based on Tiger
- ARC Search: ARC-developed program to search for evidence of hacker activity
The checklist is divided into several categories with links to descriptive text that explains the action and the need for it. For each item, a recommended method is provided. For instance, areas that TARA supports are annotated with “TARA”. Items that require manual intervention are designated by “Administrator Action”. These items are a decided as a function of organizational policy (e.g., password aging, access control), and system familiarization (expired accounts, usage, super-user privileges).
Critical Actions
External Auditing: |
Verifying the security configuration from the “outside” |
Correct Critical Problems |
SARA |
Correct Serious Problems |
SARA |
Review Potential Problems |
SARA |
|
|
Internal Auditing |
Verifying the security configuration from the “inside” |
Run Automated Checklists |
TARA |
Run ARC Hacker Search program |
ARC |
Confirm patches are up to date |
Administrator Action |
|
|
“rhosts” files: |
Remotelogin utilities |
Check hosts.equiv |
TARA |
Check all .rhosts |
TARA |
Check .netrc |
TARA |
|
|
Passwords: |
User authentication |
Check for password aging |
Administrator Action |
Remove old accounts |
Administrator Action |
Check accounts with no passwords |
TARA, SARA, ARC |
Check password security provisions |
Administrator Action |
|
|
Super User: |
Protecting system privileges |
Check root access limits |
TARA |
Check who is using it |
Administrator Action |
Confirm password is “bulletproof” |
Administrator Action |
|
|
Network Services: |
Remote access from ‘the world’ |
Identify non-required services from inetd |
SARA |
Identify non-required standalone services |
SARA |
Check Web services |
TARA |
Limit access to services |
Administrator Action |
Important Actions
NFS: |
Network File System |
Confirm that it is needed or disable |
Administrator Action |
Confirm suid is disabled |
TARA |
Confirm portmapper isn’t “buggy” |
SARA |
Review exports and netgroup |
TARA, SARA |
Review system permissions |
TARA |
Confirm the nobody/nogroup IDs |
TARA |
Other
Miscellaneous |
Other Things to Consider |
Tighten up login banners |
Administrator Action |
Install secure shell (ssh) |
Administrator Action |
Consider one-time passwords |
Administrator Action |
Don’t forget SMB emulators |
Administrator Action |
External Auditing Software
These are programs that examine other systems to evaluate what possible entry points they present to the outside world. You should be careful when using them that you have the permission of the administrators of the scanned systems, since they may perceive an unauthorized scan as an attack.
Current network security audit programs include:
Each program ranks the problem found by level of severity. SARA categorizes a problem in the following way:
- Critical (Red): Compromise of accounts and/or large amounts of data.
- Serious (Yellow): Compromise of data and/or simplify hacker’s job.
- Possible (Brown): Possible compromise target. Not enough information is known.
For each type of problem found, these packages offer a tutorial that explains the problem and what its impact could be. The tutorial also explains what can be done about the problem: correct an error in a configuration file, install a bugfix from the vendor, use other means to restrict access, or simply disable service. All major vulnerabilities uncovered by any of these auditors should be corrected before continuing! Here’s a summary of current list of capabilities (The SARA indicator specifies the given feature is new or improved under SARA):
- Built-in report writer (by subnet or by database) SARA
- FTP bounce
- Mail relaying
- Built-in summary table generator SARA
- Gateway to external programs (e.g., NMAP) SARA
- CGI-BIN vulnerability testing (Unix and IIS) SARA
- SSH buffer overflow vulnerabilities SARA
- Current Sendmail vulnerabilities SARA
- IMAPD/POPD buffer overflow vulnerabilities SARA
- Current FTP and WU-FTP vulnerabilities SARA
- Tooltalk buffer overflow vulnerabilities SARA
- Netbus, Netbus-2, and Back Orifice vulnerabilities SARA
- Improved Operating System fingerprinting SARA
- Firewall-aware SARA
- Probing for non-password accounts
- NFS file systems exported to arbitrary hosts
- NFS file systems exported to unprivileged programs
- NFS file systems exported via the portmapper
- NIS password file access from arbitrary hosts
- REXD access from arbitrary hosts
- X server access control disabled
- Arbitrary files accessible via TFTP
- Remote shell access from arbitrary hosts
- Writeable anonymous FTP home directory
Internal SecurityAuditing
These are programs that are run on the system to evaluate its security with respect to a canned checklist. There is some overlap between what these programs do and this checklist.
- The ARC Search Program scans the host’s local drives for many common hacker programs that might be installed on the target system.
- Texas A&M University’s Tiger scripts is the basis for TARA. These are similar to the Computer Oracle and Protection System (COPS), but expands on it. From the TIGER documentation:
“This is a set of Bourne shell scripts, C programs and data files which are used to perform a security audit of UNIX systems. . . . TIGER has one primary goal: report waysroot can be compromised. Paths into root are all checked to see if anyone other than root can alter that path. “
Some things that are checked:
.rhosts & .netrc files Specific file & directory access permissionsFile system scans to locate unusual files
Digital signatures are used to detect alterations to key binaries and also to report binaries for which (updated) security patches exist.
Pathnames embedded in any files reported by most of the other checks are also checked.
rhosts and hosts.equiv User account .rhosts files should not contain machine names not located at NIH. Use one of the internal auditing programs mentioned below to scan for insecure .rhosts entries.
- Remove /etc/hosts.equiv and /.rhosts unless you have some overriding need for them. Since some system intrusions involve creating one of these files where none existed before, you can confound attempts to create them by creating a directory of the same name.
For instance:
mkdir /.rhosts
touch /.rhosts/x
chmod 0 /.rhosts/x
chmod 0 /.rhosts
- Check if
- Test the functionality of the /etc/hosts.equiv file for the ability to use the "* -user name" syntax to deny trusted logins from any system and username pair. If this syntax does not work, then a source code patch to the ruserok() routine will be necessary. If a patch is not available, the system name can not be placed in the /etc/hosts.equiv file. Verify that /etc/hosts.equiv has no ambiguous entries. This means that the fully qualified name is first and any aliases second rather than the reverse. Make sure that there are NO ‘+’ entries.
- Don’t forget to check the .netrc file as it has similar effects to FTP access. Wherever possible, remove the .netrc!
Improve Password Security
Password security is the first and most powerful line of defense. Password security on Unix systems can be improved by doing the following:
- Review your password policy to confirm that some type of password aging is in place. Password aging should be in accordance with the CIO’s policy guidelines.
- Periodically review the accounts on your system. Determine which accounts are no longer active and remove them.
- Implement shadow password and group files to restrict access to the encrypted password information. If an intruder can get a copy of your /etc/passwd file which contains encrypted passwords, then (s)he can use a password cracking program on a remote (possibly more powerful) host to test guessed passwords against each password entry. Shadow password and group files protect the encrypted passwords.
- Run a password cracking program such as crack to check for poor passwords.
Protect Superuser Access Do not allow direct root logins, except maybe from the console, if it is in a physically secure location. Only terminals marked as secure in the file /etc/ttytab file will allow any user with UID = 0 to login directly. At all other terminals the user will need to login as a normal user and then su to root. Marking terminals as unsecured is a good idea, although not necessary.
Example /etc/ttytab:
console "/usr/etc/getty std.9600" sun on local unsecure ttya "/usr/etc/getty std.9600" vt100 off local unsecure ttyd0 "/usr/etc/getty std.19200" dialup on unsecure tty00 "/usr/etc/getty std.9600" unknown off local unsecure ttyp0 none network off unsecure
- Limit the users who are allowed to
- For new Linux systems, the file /etc/securetty controls remote root access. If any entry has the value ttyp, then remote root logins are possible. For newer SunOS and IRIX, systems, remote root access is controlled by /etc/default/login. If the entry, #CONSOLE=xxxxx is found, then remote root logins are possible.
- Log and monitor su activity. su information can be logged in a separate file by editing /etc/syslog.conf:
On a regular basis monitor the sulog by looking at the file, or having it mailed to you.
- Use a program such as sudo in place of su to avoid giving people unrestricted root access.
Quoting from the README file from sudo version 1.3.1:
Sudo is a program designed to allow a sysadmin to give limited root privileges to users and log root activity. The basic philosophy is to give as few privileges as possible but still allow people to get their work done.
Review which network services you wish to provide to other systems
Listener Services
The Internet services daemon, usually called inetd, controls most -- but not all -- of the services your system provides to the rest of the world. If you are connected to the Internet, you should interpret the phrase “rest of the world” quite literally.
- Edit the file /etc/inetd.conf and disable (by placing a “#” in column 1) all services which you don’t plan to use. Remember: You need to not only protect against known vulnerabilities, but also the possibility that some newlydiscovered vulnerability will affect your system. If a particular service is not enabled, no one can use it to break into your system.
- For those services you wish to provide, consider restricting their use to known friendly sites, and/or logging their use. This can sometimes be done by substituting a more secure daemon program for the one provided by your vendor, running the existing daemon in conjunction with TCP Wrappers, or using William LeFebvre’s securelib, which allows an access control list to be created for socket bind requests from remote hosts. securelib has libc replacements for the socket functions accept, recvfrom, and recvmsg which are installed in your libc.so shared library.
Here’s a quick rundown of the more common inetd services:
ftp - If you don’t plan to set up an incoming FTPserver, disable this. If you do need to run an FTPserver, consider using an FTPdaemon that has added logging and accesscontrol features such as the wuarchive ftpd. telnet, shell, login, exec - Allows users from other systems to log into your machine. This is useful, but the more useful something is, the more likely that someone will find a way to exploit it. If you have no need to login remotely, disable it. If you do need to allow remote logins, consider using a one-time password system or ssh if possible. comsat - This is a daemon which is used to notify users of newlyarrived email. There are alternate means of doing the same thing, and there are occasional rumors of security problems with comsat. Unless you have some overwhelming need for this, turn it off. talk - Allows users to communicate by typing at eachother’s terminals. Cute, but usually not needed. If you want to use it, consider using the TCPwrapper package.- uucp - Disable this if you don’t use uucp. While you’re at it, you may as well turn off execute permission on the uucp-related shell commands.
tftp dgram udp wait root in.tftpd -s /tftpboot
If you don’t,
tftp can be used to retrieve any file from your system, anonymously. Also make all the files in the bootfile directory read-only. finger - This hands out information on who is loggedin, or people’s phone numbers and offices. Unfortunately this information can be used by a potential intruder to find accounts to attack. You may wish to disable this, run a custom finger daemon, or use the TCP Wrapper package on it. systat, netstat - These give out information about your system. The comments for finger apply to these. time - Probably safe. echo, discard, daytime, chargen - These are used for testing, and are generally safe, though there have been reports of TCP packets with forged IP source addresses being used to trick a system into sending echo packets to itself, causing a packet storm on the local ethernet segment. mountd - Part of the NFS system. Usually started from /etc/rc anyway. rexd - This is the Remote Procedure Call mechanism. It has minimal authentication, so unless you really need it you should turn it off. walld - This allows people to send messages to all logged in users. Useful, but easily abused. You’ll probably want to disable it or restrict it with TCP Wrappers. Tooltalk – (ttdbserverd) This is used by many common desktop elements. However, serious remote exploits may encourage disabling this feature. Experience has indicated little operational degradation by disabling this.
Standalone Services
Many services are not controlled by inetd but rather are spawned during the boot process. These so called standalone daemons do not use inetd so TCP Wrappers will have no effect. Review in the process status display (ps -aux or ps -def) what daemons are running. If you see any that you think that you may not need, kill it and see what happens (be sure that you are the only user). If you decide that you don’t need it, rename it in one of the /etc/rc*.d directories. For instance, if you do not want sendmail, rename the S80Sendmail file in /etc/rc.d to disable.S80Sendmail.
TCP Wrappers
Weitze Venema’s TCP Wrapper package permits you to specify an accesscontrol list to restrict each network service you support -- such as telnet or FTP -- by site, domain or username, and log all network service requests. It also lets you specify arbitrary actions -- such as fingering the client site or generating email -- to be executed in response to a network request. You can also run a nonstandard process in place of the regular daemon for specific sites.
The Network File System: NFS
NFS
is a notorious security problem. If you must NFS mount a remote file system, be sure to:- Mount it with the nosuid option. On the mount command supply the arguments:
-o nosuid
or use the keyword
nosuid in the options field of the /etc/fstab file.- Mount it readonly if possible. On the mount command supply the arguments:
-o ro
or use the keyword
ro in the options field of the /etc/fstab file.If you must export file systems via NFS:
- Export file systems only when necessary, and then only to hosts that require them.
- Export only to fully qualified hostnames.
- Ensure that export lists do not exceed 256 characters. If you use aliases, the list should not exceed 256 characters AFTER the aliases have been expanded.
There is a bug in some implementations ofNFS where an export list longer than 256 characters causes the server to export your filesystems unrestricted to the entire world, without giving any warning that it is doing so.
- Explicitly list who you plan to export to in the
-access=
machine1:machine2:machine3- Export the directories readonly if this is feasible in your circumstance. Use the
- Turn on port monitoring. This will cause the NFS mount daemon to refuse mount requests originating from highnumbered ( = 1024) ports. The significance of this is that there is a Unixwide convention that a nonroot process may not open a lownumbered port, thus if you enable port monitoring the theory is that your system will accept mount requests only from privileged processes. This is a convention only, and there is nothing to prevent an untrustworthy Unix system, or almost any other type of system from violating it. While enabling port monitoring is worthwhile because it’s easy, it also doesn’t buy you a whole lot of security. All that aside, here’s how: The default /etc/rc.local sets up port monitoring only if the file /etc/security/passwd.adjunct exists. If you will be implementing passwordfile shadowing then you can skip over this step. If you will not be implementing shadowing and you will be exporting files then you should modify /etc/rc.local to do the following, regardless of whether the /etc/security/passwd.adjunct file exists:
Some NFS clients to which you may be attempting to provide service, may not be able to cope with this, in which case you won’t be able to do it.
- Insure that all system programs and system directories (including all parent directories all the way up to root) are owned by root, rather than some other user such as bin. The reason for this is that NFS treats numeric userids as equivalent between systems, except for root which it maps to nobody. If say, the executable files in /bin are owned by bin, a malicious sysadmin on another system could NFS mount this directory and overwrite the files.
- If you have a firewall, do not pass TCP or UDP packets to ports 111 (the portmapper) or port 2049 (the NFS daemon) from outside your organization. Depending on the level of security you desire, you may decide to restrict the range of addresses from where you accept such packets to some trusted subset of your organization.
- In order to protect yourself from a wellknown NFS attack, you must do at least one of the following, but preferably both:
- Do NOT selfreference an NFS server in its own exports file either by name, or by the loopback address: localhost.
- Use a portmapper that disallows proxy access. Be sure that you do this for every host that runs a portmapper. For Solaris 2.x, use a version of rpcbind that disallows proxy access.
- Run the command:
showmount -e
to determine if what you think you’re exporting is what you’re really exporting.
If you won’t be running NFS, you shouldn’t run the NFS daemon, or the mountdaemon. By insuring that the file
/etc/exports doesn’t exist, /etc/rc.local will not start nfsd or mountd.Verify that a safe uid is assigned to ‘nobody’ and ‘nogroup’. Several utilities (NFS, rdist) which transfer files or permissions between systems do so by comparing the numeric userid. When one of these utilities is attempting access between two systems that have different wordsizes, the truncation or signextension rules which apply to the particular hardware come into play, which may inappropriately equivalence two userids. Some Unix installations use -2 as the userid for nobody and nogroup. Since negative numbers are subject to such hardwaredependent mangling, you should use a number such as 65534 (binary 1111111111111110) or 32767 (binary 0111111111111111).
Miscellaneous Secure Shell
From the README file:
“Ssh (Secure Shell) is a program to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another. It provides strong authentication and secure communications over unsecure channels. It is intended as a replacement for rlogin, rsh, and rcp.
Additionally,ssh provides secure X connections and secure forwarding of arbitrary TCP connections. “
- Login Banners
A banner should be placed on your system so that users will see it either before login or right after they have loggedon.
This may not seem an important security measure, but if you ever wind up prosecuting a system breakin in court, this will help in establishing that the intruder was aware that they were trespassing.
The banner should state:
- Who owns the system.
- Who is authorized to use the system.
- The fact that unauthorized use is illegal/in violation of your policy/frowned upon.
- If users’ activities will be monitored, and what will be done with the data gathered by such monitoring.
Caveat:
This is an illdefined legal area, with few precedentsetting cases to determine what will stand up in court and what won’t. We advise that you consult your legal staff before deciding on the exact wording of your banner.An example is:
THIS UNITED STATES GOVERNMENT COMPUTING SYSTEM IS FOR AUTHORIZED OFFICIAL USE ONLY. Unauthorized use or use for other than official U. S. Government business is a violation of Federal Law (18 USC).
Individuals using this computing system are subject to having all of their activities on this system monitored and recorded without further notice. Auditing of users may include keystroke monitoring.
Any individual who uses this system expressly consents to such monitoring and is advised that information about their use of the system may be provided to Federal law enforcement or other authorities if evidence of criminal or other unauthorized activity is found.
This should be modified as appropriate for your situation.
- OneTime Passwords
Ordinarily, when you login you are asked for an accountname and a password. If this information is compromised -- as for instance if someone is monitoring your connection -- it can be used to gain access to your account. With a onetime password system your password will be different each time you login. If one of these passwords is discovered by someone else, it will be useless to them. There are several commercial OneTime Password systems available, but there are also a few freely available systems.
- S/Key is perhaps the bestknown of these.
- OPIE is a “new and improved” version of S/Key. The underlying algorithm is about the same, but the commandsyntax has been changed to make it more closely resemble the equivalent Unix commands they replace.
With both these (and similar) systems, you are not expected to memorize a long list of passwords. You can either generate them on the fly, using a laptop or other local computer to which you have direct (console) access, or carry a paper list of passwords. The systems can be configured to allow you to login using a regular reusable password when you are loggingin locally, using a trusted channel.
- SMB Emulators
Service Message Block (SMB) emulators, such as SAMBA, provide the functionality of Windows NT file/print servers on Unix platforms. With this capability comes the danger of improperly secured file shares. You should insure that the shares (for SAMBA, defined in smb.conf) are properly restricted. If your SMB emulator if intended only for your workgroup, you can restrict access by setting the hosts_allow entry in smb.conf.
sysctl
Recommended Settings
sysctl_config: # Disable IPv4 forwarding. net.ipv4.ip_forward: 0 # Ignore ICMP redirect net.ipv4.conf.all.send_redirects: 0 net.ipv4.conf.default.send_redirects: 0 # Do not send ICMP redirects net.ipv4.conf.all.accept_redirects: 0 # Syncookies is used to prevent SYN-flooding attacks. net.ipv4.tcp_syncookies: 1 # Disable forwarding of source-routed packets net.ipv4.conf.default.accept_redirects: 0 net.ipv4.conf.all.accept_redirects: 0 net.ipv4.conf.default.secure_redirects: 1 net.ipv4.conf.all.secure_redirects: 0 net.ipv4.conf.all.accept_source_route: 0 net.ipv4.conf.default.accept_source_route: 0 # Disable forwarding of directed broadcasts net.ipv4.icmp_echo_ignore_broadcasts: 1 # Disable IPv6 net.ipv6.conf.all.disable_ipv6: 1 # Unestablished connections queue net.ipv4.tcp_max_syn_backlog: 1024 # Set ARP Cache timeout net.ipv4.neigh.default.base_reachable_time_ms: 60000 # Reduce keepalive interval to one second net.ipv4.tcp_keepalive_intvl: 1 # Reverse path filtering - IP spoofing protection net.ipv4.conf.all.rp_filter: 1 net.ipv4.conf.default.rp_filter: 1 # Ignore bad ICMP errors net.ipv4.icmp_ignore_bogus_error_responses: 1 # Log spoofed, source-routed, and redirect packets net.ipv4.conf.all.log_martians: 1 net.ipv4.conf.default.log_martians: 1 # Implement RFC 1337 fix net.ipv4.tcp_rfc1337: 1 # Randomize addresses of mmap base, heap, stack and VDSO page kernel.randomize_va_space: 2 # Provide protection from ToCToU races fs.protected_hardlinks: 1 fs.protected_symlinks: 1 # Make locating kernel addresses more difficult kernel.kptr_restrict: 1 # Set ptrace protections kernel.yama.ptrace_scope: 1 # Set perf only available to root kernel.perf_event_paranoid: 2 # CIS 1.5.1 Ensure core dumps are restricted fs.suid_dumpable: 0 # CIS 1.5.3 Ensure address space layout randomization (ASLR) is enabled kernel.randomize_va_space: 2
all vs. default in sysctl
Documentation for sysctl does state that using all (e.g. net.ipv4.conf.all.* changing the parameter for all interfaces) will automatically apply the same setting to default (e.g. net.ipv4.conf.default.* changing the parameter for any future interfaces). This however, I have not found in practice. Here is a working example:
[root@my-host ~]# ethtool -i eth1 driver: virtio_net version: 1.0.0 firmware-version: expansion-rom-version: bus-info: 0000:00:05.0 supports-statistics: no supports-test: no supports-eeprom-access: no supports-register-dump: no supports-priv-flags: no [root@my-host ~]# echo "0000:00:05.0" > /sys/bus/pci/drivers/virtio-pci/unbind [root@my-host ~]# ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1460 inet 10.71.200.38 netmask 255.255.255.255 broadcast 10.71.200.38 ether 42:01:0a:47:c8:26 txqueuelen 1000 (Ethernet) RX packets 4022 bytes 1176451 (1.1 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 3161 bytes 424278 (414.3 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 loop txqueuelen 1 (Local Loopback) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 [root@my-host ~]# ethtool -i eth1 Cannot get driver information: No such device [root@my-host ~]# sysctl -ar "net.ipv4.*.send_redirects" net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf.eth0.send_redirects = 0 net.ipv4.conf.lo.send_redirects = 1 [root@my-host ~]# echo "0000:00:05.0" > /sys/bus/pci/drivers/virtio-pci/bind [root@my-host ~]# sysctl -ar "net.ipv4.*.send_redirects" net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf.eth0.send_redirects = 0 net.ipv4.conf.eth1.send_redirects = 0 net.ipv4.conf.lo.send_redirects = 1 [root@my-host ~]# ethtool -i eth1 driver: virtio_net version: 1.0.0 firmware-version: expansion-rom-version: bus-info: 0000:00:05.0 supports-statistics: no supports-test: no supports-eeprom-access: no supports-register-dump: no supports-priv-flags: no [root@my-host ~]# ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1460 inet 10.71.200.38 netmask 255.255.255.255 broadcast 10.71.200.38 ether 42:01:0a:47:c8:26 txqueuelen 1000 (Ethernet) RX packets 4174 bytes 1199179 (1.1 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 3263 bytes 440790 (430.4 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 loop txqueuelen 1 (Local Loopback) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 [root@my-host ~]# ifconfig eth1 up [root@my-host ~]# ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1460 inet 10.71.200.38 netmask 255.255.255.255 broadcast 10.71.200.38 ether 42:01:0a:47:c8:26 txqueuelen 1000 (Ethernet) RX packets 4220 bytes 1203287 (1.1 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 3296 bytes 445181 (434.7 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 ether 42:01:0a:84:00:02 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 loop txqueuelen 1 (Local Loopback) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 [root@my-host ~]# sysctl -ar "net.ipv4.*.send_redirects" net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf.eth0.send_redirects = 0 net.ipv4.conf.eth1.send_redirects = 0 net.ipv4.conf.lo.send_redirects = 1
[root@my-host ~]# sysctl -w net.ipv4.conf.default.send_redirects=1 net.ipv4.conf.default.send_redirects = 1 [root@my-host ~]# sysctl -ar "net.ipv4.*.send_redirects" net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.send_redirects = 1 net.ipv4.conf.eth0.send_redirects = 0 net.ipv4.conf.eth1.send_redirects = 0 net.ipv4.conf.lo.send_redirects = 1 [root@my-host ~]# echo "0000:00:05.0" > /sys/bus/pci/drivers/virtio-pci/unbind [root@my-host ~]# sysctl -ar "net.ipv4.*.send_redirects" net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.send_redirects = 1 net.ipv4.conf.eth0.send_redirects = 0 net.ipv4.conf.lo.send_redirects = 1 [root@my-host ~]# echo "0000:00:05.0" > /sys/bus/pci/drivers/virtio-pci/bind [root@my-host ~]# sysctl -ar "net.ipv4.*.send_redirects" net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.send_redirects = 1 net.ipv4.conf.eth0.send_redirects = 0 net.ipv4.conf.eth1.send_redirects = 1 net.ipv4.conf.lo.send_redirects = 1
[root@my-host ~]# sysctl -w net.ipv4.conf.all.send_redirects=0 net.ipv4.conf.all.send_redirects = 0 [root@my-host ~]# sysctl -ar "net.ipv4.*.send_redirects" net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.send_redirects = 1
This shows that the default options should be set as well. There are discussions around other sysctl options acting differently, but rather than go digging to find out which ones, I think if you want them the same, just explicitly set them.