On Monday 15 April 2002 10:18 am, Raymond Leach wrote: > Hi > > Can someone explain this log line to me? It seems as though it is a > response to a http request, but there was no request. > > Apr 15 11:10:00 firefly kernel: DROP INPUT INTERNAL: IN=eth2 OUT= > MAC=00:01:02:50:b8:45:00:02:b3:35:82:bf:08:00 SRC=10.0.0.11 DST=10.0.0.2 > LEN=64 TOS=0x00 PREC=0x00 TTL=128 ID=16618 DF PROTO=TCP SPT=80 DPT=41543 > WINDOW=17520 RES=0x00 ACK SYN URGP=0 > Apr 15 11:10:03 firefly kernel: DROP INPUT INTERNAL: IN=eth2 OUT= > MAC=00:01:02:50:b8:45:00:02:b3:35:82:bf:08:00 SRC=10.0.0.11 DST=10.0.0.2 > LEN=64 TOS=0x00 PREC=0x00 TTL=128 ID=16625 DF PROTO=TCP SPT=80 DPT=41543 > WINDOW=17520 RES=0x00 ACK SYN URGP=0 > > What is even more puzzling (to me at least) is the status bits > (ACK SYN). How can this be?
Starting with the last question first, SYN + ACK is the standard response to a SYN packet - it's the second packet (first reply) in the so-called TCP Three-way Handshake: Client sends packet with SYN set. Server send packet with SYN + ACK set. Client sends packet with ACK set. Then they're talking and data transfers can start; all further packets have the ACK bit set. Your logfile lines above show an input interface (eth2) but no output interface, therefore the packets are addressed to the Firewall itself (ie they're not trying to be forwarded through it). If we assume that your Firewall didn't generate a request to port 80 on the server listening on 10.0.0.11, then I can think of two possible situations which could cause this effect in the log file: 1) A packet was sent either through the Firewall or from a machine on the internal network connected to eth2 with a spoofed source address of 10.0.0.2, causing the reply to go back to that address (which is the Firewall) 2) A connection was attempted through the Firewall, with some address translation rules which caused the request to arrive at the server on 10.0.0.11 with a source address of 10.0.0.2, but either the Firewall wasn't doing full connection tracking, or you don't accept ESTABLISHED, RELATED packets automatically back through the machine, therefore the Firewall itself tried to deal with the response packet instead of sending it back to the initiating client. Hope this helps, Antony.
