[Dshield] Increase in probes *from* port 80, to random ports

Johannes Ullrich jullrich at sans.org
Tue Jun 18 00:13:30 GMT 2002

probes from port 80 are a bit tricky. You have to look very carefully at
flags and other parameters to distinguish the good and bad once.

If you are using and 'establish, related' rule to allow traffic in based
on client requests, there are two main reason why iptables may flag packets
that should fall under this rule:

1) Timeouts. iptables has to store information for each connection it is
tracking. To recycle memory used for dead connections, some timeouts are
applied. The only way I know of to change these timeouts is in your kernel
source and recompile. They are kept in  

look for this block:

static unsigned long tcp_timeouts[]
= { 30 MINS,    /*      TCP_CONNTRACK_NONE,     */
    5 DAYS,     /*      TCP_CONNTRACK_ESTABLISHED,      */
    2 MINS,     /*      TCP_CONNTRACK_SYN_SENT, */
    60 SECS,    /*      TCP_CONNTRACK_SYN_RECV, */
    2 MINS,     /*      TCP_CONNTRACK_FIN_WAIT, */
    2 MINS,     /*      TCP_CONNTRACK_TIME_WAIT,        */
    10 SECS,    /*      TCP_CONNTRACK_CLOSE,    */
    60 SECS,    /*      TCP_CONNTRACK_CLOSE_WAIT,       */
    30 SECS,    /*      TCP_CONNTRACK_LAST_ACK, */
    2 MINS,     /*      TCP_CONNTRACK_LISTEN,   */

Basically, it tells you how long a connection is kept in memory if it reaches
a given state (e.g. 5 days once it is 'established').

The tricky parts are the establishing phase (SYN_SENT, SYN_RECV) and the
'CLOSE' phase. You may want to increase these values if you have only few
clients and free memory on your machine. The default values are 'safe':
During the build up phase, the timeouts are rather short to help with simple
DOS attacks, while established connections are held 'forever' (5 days without
traffic is a long time). 

2) closing phase. I find that iptables drops a lot of connections a bit early
during the closing phase. Again, this is probably done with safety in mind.
These connections are doing to be closed anyway, so it is better to be careful.
The only workaround I found is not to log everything. Take a look at frequent
flag combinations that get ditched and logged. Take a looks where they come from
and if the source looks 'safe', disable logging for these flag combos (but don't
allow them in blindly.)

One nice way to debug this:
If you network is not very busy (and if your companies privacy policy allows you
to do this), log all packet headers for a while. Now you can go back later and
check for connections flagged by iptables what the history was.

On 17 Jun 2002 15:15:46 -0700
Kenneth Porter <shiva at sewingwitch.com> wrote:

> On Mon, 2002-06-17 at 10:04, Lauro, John wrote:
> > 76% are ACK SYN
> > 6% ACK RST
> > 18% just ACK
> FWIW, I'm seeing similar activity, but mostly ACK's. Topology is single
> public static IP NAT'ing about 70 workstations, using iptables. Prior to
> using iptables, I used ipchains, which lacked the ability to detect this
> kind of thing. The masquerading feature of ipchains used high port
> numbers (> 60000) when NAT'ing outgoing connections. I don't know if
> iptables does the same, but the destination port numbers I'm seeing are
> definitely below this range, and there should be no web activity sourced
> from the NAT box itself.
> In a few cases I tried to connect to the problem IP's and found either
> no web server or a virgin IIS installation.
> _______________________________________________
> Dshield mailing list
> Dshield at dshield.org
> To change your subscription options (or unsubscribe), see: http://www.dshield.org/mailman/listinfo/list

jullrich at sans.org             Collaborative Intrusion Detection                                               join http://www.dshield.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.dshield.org/pipermail/list/attachments/20020617/7bd38247/attachment.bin

More information about the list mailing list