Hardening - ICMP

English Network/Internet
#1

I am trying to set the following to 0

  • net.ipv4.conf.all.secure_redirects
  • net.ipv4.conf.default.secure_redirects

I’ve added the following to /etc/sysctl.conf and have rebooted the system:

Disable response to broadcasts.

You don’t want yourself becoming a Smurf amplifier.

net.ipv4.icmp_echo_ignore_broadcasts = 1

enable route verification on all interfaces

net.ipv4.conf.all.rp_filter = 1

enable ipV6 forwarding

#net.ipv6.conf.all.forwarding = 1

increase the number of possible inotify(7) watches

fs.inotify.max_user_watches = 65536

avoid deleting secondary IPs on deleting the primary IP

net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.all.promote_secondaries = 1

disable ICMP redirects

net.ipv4.send_redirects = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
net.ipv4.tcp_timestamps = 0

But when I run /sbin/sysctl -a, I still see the following:

net.ipv4.conf.default.secure_redirects = 1
net.ipv4.conf.all.secure_redirects = 1

I then run /sbin/sysctl -p, and get the following output:

net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.rp_filter = 1
fs.inotify.max_user_watches = 65536
net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.all.promote_secondaries = 1
/proc/sys/net/ipv4/send_redirects: No such file or directory
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
net.ipv4.tcp_timestamps = 0

I then run /sbin/sysctl -a and see the following:

net.ipv4.conf.default.secure_redirects = 0
net.ipv4.conf.all.secure_redirects = 0

However, after I reboot and run /sbin/sysctl -a, I still see the following:

net.ipv4.conf.default.secure_redirects = 1
net.ipv4.conf.all.secure_redirects = 1

How can I get those two attributes to permanently be set to 0?

#2

Every time I’ve fought with sysctl stuff in this way the problem has been
caused by either changing networks or doing something else that refreshes
the firewall. The SuSEfirewall2 service appears to do some sysctl hacking
automatically and I’ve never figured out how to trump it other than by
adding a custom firewall script to the end of the SuSEfirewall2 version
which runs the sysctl commands manually after any firewall change. This
is not pretty, but it works reliably,at least on SUSE Linux Enterprise
Server (SLES) 11.

Look at the /etc/sysconfig/SuSEfirewall2 file, for the name of the custom
script (/etc/sysconfig/scripts/SuSEfirewall2-custom); uncomment the line,
and then modify that file (it should already exist waiting for input)
adding your sysctl command to the correct section. The correct section
could probably be ‘fw_custom_after_finished’ if nothing else works.

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

#3

There is an alternative method to modifying sysctl.conf.

Although in a “paper” I wrote years ago that modifying the sysctl.conf is the preferred and universal method, the acceptable alternative is to invoke commands modifying on boot is to create an rcX.d script (which of course will work only as long as such scripts are still supported on systemd which for now seems to be indefinitely).

https://sites.google.com/site/4techsecrets/optimize-and-fix-your-network-connection/tcp-buffer-re-sizing/persisting-tcp-buffer-and-congestion-control-algorithm-changes

Referencing my above, the rcX.d script would contain lines that write your sysctl changes which would be executed on boot, (see my link for more examples)

sysctl -w* parameter=value *

Also, you might try the method I described in my paper which is to enter the full “write command” in your sysctl.conf instead of just the setting.

TSU

#4

On 10/19/2015 09:36 AM, tsu2 wrote:
>
> Although in a “paper” I wrote years ago that modifying the sysctl.conf
> is the preferred and universal method, the acceptable alternative is to
> invoke commands modifying on boot is to create an rcX.d script (which of
> course will work only as long as such scripts are still supported on
> systemd which for now seems to be indefinitely).

Note also that while this works, if the root cause is the firewall being
started/stopped (as I’ve seen in the past with things like the rp_filter
setting) the init script (or service for systemd) solution will not work
when reconfiguration/restart of the firewall alone happens, for example
when changing settings via Yast.

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

#5

A scripted approach to setting sysctl provides a workaround…
If re-starting the FW causes the settings to change, then simply re-running the script should set everything back the way things should be.

There are 2 approaches I’d try…

  • In the systemd Unit file for the FW service, I’d “exec” the script as a “post” invoke
  • If the script can’t be invoked automatically after a FW restart, then I’d simply create a symbolic link from a friendly name in the PATH so that I could manually invoke easily.

TSU

#6

On 10/23/2015 08:56 AM, tsu2 wrote:
>
> There are 2 approaches I’d try…
> - In the systemd Unit file for the FW service, I’d “exec” the script as
> a “post” invoke
> - If the script can’t be invoked automatically after a FW restart, then
> I’d simply create a symbolic link from a friendly name in the PATH so
> that I could manually invoke easily.

I agree that how you call the script is not that important, so long as you
do, whether from the firewall’s own configuration files, or from some
system level configuration that happens every time the firewall is started.

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…