Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Pat Riehecky <prieheck@iwu.edu>
To: "Gáspár Lajos" <swifty@freemail.hu>
Cc: netfilter@lists.netfilter.org
Subject: Re: Conntrack rule timeout problem
Date: Thu, 24 May 2007 09:16:53 -0500	[thread overview]
Message-ID: <1180016213.6265.41.camel@thales.lan> (raw)
In-Reply-To: <46546B8B.9040705@freemail.hu>

That is an excellent article!

I attempted to simplify the oddities I am seeing to avoid being overly
complex, but it seems that was in error....

Here is a packet that was caught on its way out of my server, it cannot
be part of a FORWARD chain as my FORWARD chain looks like this

:FORWARD DROP [0:0]
-A FORWARD -j LOG --log-prefix "Default DROP (FORWARD): " 
-A FORWARD -j DROP 

Simply put the answer to any forward is "NO"

The packet is :
Default DROP (OUTPUT): IN= OUT=eth0 SRC=192.168.12.74 DST=66.28.242.99
LEN=344 TOS=0x00 PREC=0x00 TTL=64 ID=13688 DF PROTO=TCP SPT=60155 DPT=80
WINDOW=5840 RES=0x00 ACK FIN URGP=0

It tries for a while and then gives up.  This feels identical to the
input scenario.  The last packet seems to not be getting through as
RELATED/ESTABLISHED.  After studying the flow with iptstate 
(a bit poorly, but it was a start) this seems to occur when a connection
is closed - but not when all connections are closed.  This leads me to
believe that it has to be related to conntrack.

Is my reasoning on this flawed?
Pat

On Wed, 2007-05-23 at 18:27 +0200, Gáspár Lajos wrote:
> Pat Riehecky írta:
> > I am about 90% certain that I am not being scanned as a bunch of the
> > dropped packets are coming from places like the New York Times,
> > Microsoft, and Google.  Admittedly they could be spoofed IP addresses.
> > but the packets are all coming from 80 or 443 and they are all destined
> > for TCP Ports in the ephemeral range.  Additionally in my squid logs I
> > have a corresponding entry requesting data from that server.
> >
> >   
> Well... Read this:
> 
> http://www.hackinthebox.org/modules.php?op=modload&name=News&file=article&sid=10640&mode=thread&order=0&thold=0
> 
> The interesting part starts at *"Camouflaging your ip address"...*
> > All evidence I have points to some sort of conntrack timeout.
> > Occasionally I can find the IP addresses in the output from iptstate,
> > but... 
> >
> > Thanks for the ideas, any chance for more theories?
> > Pat
> >   
> Swifty
> 



      reply	other threads:[~2007-05-24 14:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-21 16:34 Conntrack rule timeout problem Pat Riehecky
2007-05-23 12:47 ` Gáspár Lajos
2007-05-23 13:42   ` Pat Riehecky
2007-05-23 16:27     ` Gáspár Lajos
2007-05-24 14:16       ` Pat Riehecky [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1180016213.6265.41.camel@thales.lan \
    --to=prieheck@iwu.edu \
    --cc=netfilter@lists.netfilter.org \
    --cc=swifty@freemail.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox