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
>
prev parent 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