ICMP filtering best practice

There is an RFC draft "Recommendations for filtering ICMP messages". It discusses various aspects of ICMP usage and its filtering considerations for network operators. Specifically, it addresses IPv4 in the context of ICMP and provides implementation guidance for filtering or rate limiting various ICMP types.

Let's take it from there.

Operational considerations vs security implications

In a narrow context, "should you allow ICMP echo requests or not"?

ICMP error messages contain a data section that includes a copy of the entire IPv4 header, plus at least the first eight bytes of data from the IPv4 packet that caused the error message. The length of ICMP error messages should not exceed 576 bytes.[5] This data is used by the host to match the message to the appropriate process. If a higher level protocol uses port numbers, they are assumed to be in the first eight bytes of the original datagram's data.[6]

The variable size of the ICMP packet data section has been exploited. In the "Ping of death", large or fragmented ICMP packets are used for denial-of-service attacks. ICMP data can also be used to create covert channels for communication. These channels are known as ICMP tunnels.

# Block fragmented ICMP.
-A INPUT -p icmp --fragment -j DROP

# Allow incoming Path MTU Discovery (ICMP destination-unreachable/fragmentation-needed)
-A INPUT -p icmp --icmp-type 3/4 -m state --state NEW -j ACCEPT

# Allow incoming ICMP Port Unreachable to handle UDP
-A INPUT -p icmp --icmp-type 3/3 -m state --state NEW -j ACCEPT

# Allow incoming request to decrease rate of sent packets (ICMP Source Quench)
-A INPUT -p icmp --icmp-type 4 -m state --state NEW -j ACCEPT

# Allow and throttle incoming ping (ICMP type 8 Echo)
-A INPUT -p icmp --icmp-type 8 -m state --state NEW -m limit --limit 5/s --limit-burst 10 -j ACCEPT

References

IANA registry for ICMP types and codes
Recommendations for filtering ICMP messages, an expired IETF RFC draft
Recommendations for Filtering ICMPv6 Messages in Firewalls, RFC 4890
Cisco Firewall Best Practices
Path MTU Discovery on Wikipedia
Deprecation of ICMP Source Quench Messages, RFC 6633
Neighbor Discovery Protocol on Wikipedia
Discussion of attacks enabled by ICMP

Tracking Syscall Failures with auditd: What I Learned

Recently, I learned that Linux’s auditd lets you filter syscall events based on their return codes, and I found it super useful for monitoring security-related failures. Instead of drowning in logs, you can focus on failed system calls that might indicate permission issues or unauthorized access attempts. I thought I'd share some examples that I found particularly interesting.

Filtering Syscalls by Exit Code

One of the coolest things about auditd is that you can filter events based on their return codes. This means you can specifically track failed system calls due to permission errors, like EACCES (Permission Denied) or EPERM (Operation Not Permitted).

Example: Watching for Denied File Access

I wanted to see when a process tried to open a file but got denied, so I set up this rule:

-a always,exit -F arch=b64 -S open -S openat -F exit=-EACCES

What This Rule Does:

```
-a always,exit
```
: Logs every matching event when the syscall exits.
```
-F arch=b64:
```
Targets 64-bit architecture (use b32 for 32-bit systems).
```
-S open -S openat:
```
Watches file opening attempts.
```
-F exit=-EACCES:
```
Only logs events where the syscall failed due to EACCES.

Another useful example is detecting unauthorized execution attempts:

-a always,exit -F arch=b64 -S execve -F exit=-EACCES

I think tracking syscall return codes is a great technique to detect reconnaissance on a Linux system. It keeps logs manageable and helps focus on real security issues without unnecessary noise. If you haven’t tried this yet, I definitely recommend experimenting with it!