Loading...
 

UNIX System Checklist

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:

Remote­login 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 Security­Auditing

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 ways
root 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:

  • cron entries
  • mail aliases
  • NFS exports
  • inetd entries
  • PATH variables
.rhosts & .netrc files

Specific file & directory access permissions

File 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
ruserok() ignores .rhosts files which are group or world readable. If it does not ignore such files then make corrections, if possible. Remove all .rhosts entries for root if at all possible. Set /.rhosts so that no other machine is equivalent.
    • 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 user­name 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.
    • Test the passwd program to see what kind of password construction rules are enforced. If strict password construction rules are not enforced then install npasswd or passwd+.
    • 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
su to root. If in the /etc/group file or NIS map the wheel group (group 0) is not a null user list, only the members listed are allowed to su to root, all other users will be denied, even when they enter the correct root password.
    • 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 su­log 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 newly­discovered 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 FTP­server, disable this. If you do need to run an FTP­server, consider using an FTP­daemon that has added logging and access­control 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 log­in remotely, disable it. If you do need to allow remote log­ins, consider using a one-time password system or ssh if possible. comsat - This is a daemon which is used to notify users of newly­arrived 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 each­other’s terminals. Cute, but usually not needed. If you want to use it, consider using the TCP­wrapper package. tftp - Trivial File Transfer Protocol: This is FTP without any security. This should be needed only if your system will be used for booting workstations. If this is the case, you must invoke the daemon with the -s flag, as in:

 

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 logged­in, 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 access­control 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 non­standard 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 read­only 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 host­names.
    • 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 of
NFS where an export list longer than 256 characters causes the server to export your file­systems unrestricted to the entire world, without giving any warning that it is doing so.
  • Explicitly list who you plan to export to in the
/etc/exports file by using an access list:

-access=

machine1:machine2:machine3
  • Export the directories read­only if this is feasible in your circumstance. Use the
ro flag in /etc/exports.
    • Turn on port monitoring. This will cause the NFS mount daemon to refuse mount requests originating from high­numbered ( = 1024) ports. The significance of this is that there is a Unix­wide convention that a non­root process may not open a low­numbered 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 password­file 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 user­ids 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 well­known NFS attack, you must do at least one of the following, but preferably both:

 

  • Do NOT self­reference an NFS server in its own exports file either by name, or by the loopback address: localhost.
    • 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 mount­daemon. 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 user­id. When one of these utilities is attempting access between two systems that have different word­sizes, the truncation or sign­extension rules which apply to the particular hardware come into play, which may inappropriately equivalence two user­ids. Some Unix installations use -2 as the user­id for nobody and nogroup. Since negative numbers are subject to such hardware­dependent 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 log­in or right after they have logged­on.

This may not seem an important security measure, but if you ever wind up prosecuting a system break­in 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 ill­defined legal area, with few precedent­setting 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.

  • One­Time Passwords

Ordinarily, when you log­in you are asked for an account­name 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 one­time password system your password will be different each time you log­in. If one of these passwords is discovered by someone else, it will be useless to them. There are several commercial One­Time Password systems available, but there are also a few freely available systems.

  • S/Key is perhaps the best­known of these.
  • OPIE is a “new and improved” version of S/Key. The underlying algorithm is about the same, but the command­syntax 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 log­in using a regular re­usable password when you are logging­in 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:

all and default set the same
[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
all and default set differently
[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
setting all doesn’t change default
[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.