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 >
