The fields on the left are nmap-style flags, with '-f' denoting
fragmentation and T/S/F/X/N/U denoting regular TCP connect, SYN scan (ala
strobe), FIN scan, XMAS scan, Null scan and UDP scan respectively.
| . | iplog v1.8 | ippl v1.4.5 | protolog v1.0.8 |
| -sT | Y | Y | Y |
| -sF | Y* | Y | Y |
| -sF -f | Y* | Y | Y |
| -sX | Y* | N | Y |
| -sX -f | Y* | Y | Y |
| -sS | Y | Y | Y |
| -sS -f | Y | Y | Y |
| -sN | Y* | N | Y |
| -sN -f | Y* | N | Y |
| -sU | Y | Y | Y |
| Log TCP End | N | Y | N |
| DNS Cache | Y | Y | N |
| Resolve Hosts | N | Y | Y |
| IDENT Support | Y | Y | N |
| Dfl. Ignore | /etc/resolv.conf [UDP/53] | [UDP/*] [ICMP/EchoReply] | N |
| Can Ignore | PT/PR/TH* | PT/IT/SA/PR | SA/PR/TH |
(Y) Success/True
(N) Failure/False
(Y*) Iplog Scan
Detection
Iplog seems to require two bogus packets from the same source before logging
'<TCP flag> scan detected' and moving in to 'scan mode'. Hence
I suspect that there is a timeout here (haven't confirmed), and therefore
undetected scanning should be possible against hosts utilising iplog. Simply
utilise a differing IP per port scanned (probable) or wait a long time
between ports (possible) to defeat this logger.
(PT/IT/SA/PR/TH) Ignore Capabilities
These stand for Port (TCP + UDP), ICMP Type, Source Address, Protocol and
TCP Header flags respectively.
(TH*) Iplog TCP
Header Ignore
This consists of predefined alternatives and is not nearly as flexible as
that of protolog, for example.
Ippl Interesting Feature
If you remove a log file (say, /var/log/ippl/tcp.log),
logging is halted to that file until ippl is restarted.