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