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

Lauro, John jlauro at umflint.edu
Tue Jun 18 02:48:37 GMT 2002


That's well said.  Just make sure you are not too quick to ignore all
of the packets you see like this...

As I started the thread, and I am not doing NAT/masquerading, but
instead have an upstream box that is acting as a transparent proxy for
all web traffic....  all requests come from the proxy machine's IP.
Even if some original IPs did get past the transparent proxy, it
couldn't explain all the packets I see to IP addresses that don't have
a machine...

I've dropped over 70,000 packets in the last week with a source port
80 on this non tricky network.  For today, it's only 2% of the packets
compared to the packets dropped with a destination port 80 (99.9% of
the machines don't have a web server, so they are dropped at the edge
and only the 0.1% let pass).  However, packets with a source port of
80 trying to get into my network and not to the proxy server is far
more then I seen of scans for SSH, FTP and 1433 combined.  So, IMHO
70,000 packets in a week from hundreds of different source IPs is
still significant enough that it should not be dismissed too quickly
by over debugging...  Sometimes when it looks like a bad packet,
smells like a bad packet, it is...  

I will start logging all the dropped packets and automate sending them
to dshield, instead of just counting them.  I am just worried what
logging several million packets a day will do to the firewall box
compared to just dropping them...  Should be ok for now, but I might
have to stop it in the fall for performance reasons, or only turn
logging on during off peek times...  Who knows, maybe in the long run
people will learn not to probe so aggresively, and I will not have to
drop so much...

Anyways, my original question to the list was...  has anyone noticed
probes from any other source ports besides port 80?  If it wasn't for
the fact that blocking it was trivial in my network, I probably would
not have noticed the packets...  As I don't currently have a
transparent proxy running for other protocols, they would be trickier
to block, without blocking potentially legitimate traffic.

-----Original Message-----
From: Johannes Ullrich [mailto:jullrich at sans.org] 
Sent: Monday, June 17, 2002 8:14 PM
To: list at dshield.org
Subject: Re: [Dshield] Increase in probes *from* port 80, to random
ports


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  
net/ipv4/netfilter/ip_conntrack_proto_tcp.c

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




More information about the list mailing list