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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.