As it stands currently, when a NETFILTER_PKT type message is logged by
the audit daemon for ICMP type 3 messages (destination unreachable), I
get absolutely no information in that log as to who/what caused that to
be triggered by the kernel, apart from, may be, the SELinux context. I
get something like:
type=NETFILTER_PKT msg=audit(16/02/2013 07:10:28.004:7802) : action=0
hook=3 len=80 inif=? outif=eth4 saddr=10.2.7.2 daddr=10.3.0.6 ipid=21794
proto=icmp icmptype=destination-unreachable icmpcode=1
obj=system_u:object_r:web_client_pkt_t:s0
I have managed to successfully change the AUDIT iptables target to
include additional information from the original connection which caused
this ICMP type message to be emitted, though before committing and
issuing the relevant patches, I thought to seek more broad consensus as
to what I should include as additional information in that audit log.
When ICMP type 3 message is triggered (that is also valid for type 4 -
"source quench", and type 11 - "time exceeded" ICMP messages), and also
depending on the type of the original connection, the following
information is available to the modified AUDIT iptables target and could
be transferred in the audit log for that (original) connection:
IP-related properties:
~~~~~~~
1. Source IP address;
2. Destination IP address;
3. Protocol used;
4. Type of service (TOS) value of the original packet;
5. Time-to-live (TTL) value of the original packet;
6. Checksum;
7. Total length of the original packet;
TCP-related (valid only when the original connection was TCP):
~~~~~~~~~
1. Source port;
2. Destination port;
3. TCP flags of the original packet;
4. TCP sequence value of the original packet;
5. Acknowledgement sequence number of the original packet;
6. Checksum;
7. Window size value;
UDP-related (valid only when the original connection was UDP):
~~~~~~~~~
1. Source port;
2. Destination port;
3. Packet length (header + payload) of the original packet;
4. Checksum;
SCTP-related (valid only when the original connection was SCTP):
~~~~~~~~~~
1. Source port;
2. Destination port;
3. Checksum;
Please note that this is *all* the data available to the AUDIT target,
not what is (or should be) included in the audit logs!
As it stands, I have currently included the following in the AUDIT
target to be logged, though this is not final, as I am still seeking
more broad consensus, hence this email:
IP-related properties: Source & destination IP addresses, protocol and
total length of the original packet;
TCP-related: Source & destination ports, TCP flags;
UDP-related: Source & destination ports;
SCTP-related: Source & destination ports;
As already mentioned, there are at least two things I am still
considering: 1) should I add/exclude some of what I just listed above?;
and 2) what should be the structure of the audit message?
For the latter, I have currently placed everything in a single audit
message: the properties of the ICMP audit message (as shown in the
example above), plus the field name/value pairs of the original
connection added after that. They are currently named as "oX=V", where
"X" is the brief description of the property in question and "V" is its
value (in other words, TCP source port with a value of 443 of the
original connection is constructed as "osport=443" in the final audit
message).
I would like to know whether there are any objections, new ideas or
suggestions to the above before committing this and issuing the relevant
patches. Thanks!
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
