Posted: 28th July 2010 by admin in Linux
Tags: firewall, logs, netfilter
Here is a quick reference for the format used by the netfilter log messages.  This is all derived from the source of the netfilter kernel modules (Linux kernel 2.4.2).
Below is a hypothetical log message generated by netfilter. It is based on a real log entry but I have added all possible IP and TCP flags as well as a fragment offset for illustrative purposes.
| Apr 16 00:30:45 megahard kernel: |
|
OUT= |
|
| MAC=00:80:8c:1e:12:60:00:10:76:00:2f:c2:08:00 |
|
| SRC=211.251.142.65 |
|
DST=203.164.4.223 |
|
LEN=60 |
|
| TOS=0x00 |
|
PREC=0x00 |
|
TTL=44 |
|
ID=31526 |
|
CE |
|
DF |
|
MF |
|
FRAG=179 |
|
OPT (072728CBA404DFCBA40253CBA4032ECBA403A2CBA4033ECBA40
2C1180746EA18074C52892734A200) |
| PROTO=TCP |
|
SPT=4515 |
|
DPT=111 |
|
SEQ=1168094040 |
|
ACK=0 |
|
| WINDOW=32120 |
|
RES=0x03 |
|
URG |
|
ACK |
|
PSH |
|
RST |
|
SYN |
|
FIN |
|
URGP=0 |
|
OPT (020405B40402080A05E3F3C40000000001030300)
Read the rest of this entry »
Posted: 28th July 2010 by admin in Linux
Tags: firewall, logs, netfilter
Positives
- Netfilter logs are intuitive and easy to read by the occasional, non-expert admin.
- They provide much more information than f.e. ipchains, in particular about the transport protocol.
- Show the header of messages returned inside an ICMP packet.
Consistency Issues
- Most items in the log use the LABEL=value format, but:
flags appear on their own,
options use “OPTÂ (abc..)“, and
incomplete is flagged like this: “INCOMPLETEÂ [12Â bytes]“!
The latter would also be much more useful if it showed the data:
“INCOMPLETE=0050445ACAFEAFFEEFFAEFAC“.
- The TOS field is ripped apart into “TOS” and “PREC”. This is particularly bad because TOS is increasingly being replaced by DS and ECN.
- The two MAC addresses and the type-code are thrown together into one 14 byte sequence.
- Recursive headers are enclosed in [..] but the [..] are also used for other purposes including inside a recursive header.
- Having a variable number of fields makes it impossible to quickly extract specific information. F.e. the following will fail miserably if the number of IP options varies:
awk '/DPT=53 /{printf("%s %s\n", $10, $15)} logfile'
- The user prefix ought not to allow white space. Having a variable number of spaces (from different prefixes) makes it impossible to quickly extract specific information, see previous point.
Read the rest of this entry »
Posted: 26th July 2010 by admin in Linux
Tags: firewall, ipchains
Here is a quick reference for the format used by the ipchains log messages. This is mostly taken from the ipchains-HOWTO
A typical log message generated by ipchains:
Jun 16 08:00:38 megahard kernel: Packet log: forward DENY
eth1 PROTO=17 a.b.c.d:234 w.x.y.z:34567 L=78 S=0x00 I=13413
F=0x0000 T=112 (#16)
The leading part is self explanatory. The remaining items are explained in sequence here:
| forward |
Name of the chain which was traversed by the packet |
| DENY |
action taken by ipchains |
| eth1 |
interface the packet was passing through |
| PROTO=17 |
Protocol number. A list is in your /etc/protocols. A complete list is in the file protocol-numbers |
| a.b.c.d |
source IP address |
| 234 |
source port (TCP and UDP) or the ICMP type. A list of port numbers is in your /etc/services. A complete list is in the file port-numbers |
| w.x.y.z |
destination IP address |
| 34567 |
destination port (TCP and UDP) or the ICMP code. A list of ICMP types and codes is in the file icmp-parameters |
| L=78 |
total Length of packet in bytes |
| S=0x00 |
type of Service (TOS), only 4 bits used these days, not important for firewall purposes |
| I=13413 |
IP-ID, increments with each packet sent |
| F=0x0000 |
Flags (3 bits) and Fragment offset (13 bits) |
| T=112 |
Time to live (TTL) or hops remaining before packet is dropped |
| (#16) |
rule number in the chain which matched the packet and caused the log |
More interesting files, such as multicast-addresses, can be found in http://www.iana.org/protocols/.
Read the rest of this entry »
Posted: 26th July 2010 by admin in Linux
Tags: firewall, links
Packet filtering firewall:
Linux ipchains implement a packet filtering firewall and can be considered medium security if implemented properly. A packet filtering firewall looks at each packet individually, it does not (can not) consider any previous packets which may be part of a multiple packet transaction. In other words, a packet filtering firewall is stateless.
Read the rest of this entry »
Posted: 26th July 2010 by admin in Linux
Tags: deny, firewall, reject
With ipchains you can ACCEPT, REJECT or DENY a packet. What ACCEPT does is self-explainatory, but nearly everybody asks what the difference between REJECT and DENY is and which one is better. And how does nmap see the ports?
Below is my attempt at explaining the differences. The example transactions were captured with tcpdump.
Read the rest of this entry »