On Tue, 2003-12-23 at 08:54, Antony Stone wrote: > > Yes, they are NEW because they are for a connection which netfilter has > decided is over - therefore it is no longer ESTABLISHED, and any packets > which continue to appear will be treated as a NEW connection. ESTABLISHED state is maintained for 5 days, so I'm guessing the problem is not there. When I've seen this before the traces usually show the following: *ESTABLISHED communications go fine *One side issues a FIN/ACK to tear down the connection *state timing is dropped from 5 days to 2 minutes *Other end of the connection has more data to send & Attempts transmission after the 2 min. timer expires *Packet is dropped by the firewall and logged Normally a FIN/ACK exchange takes place pretty quickly but per the RFCs one end does not have to close as well if it does not think its finished. These can cause the log entries you are experiencing. I saw this *a lot* back in the beta days when Rusty had the FIN expire set to one minute. Now that its at two minutes, it happens less frequently. Of course I have seen scanning in the wild like this that uses a fixed source port of 80 so you'll just think* that its a state issue. The scanning can identify static Vs. stateful firewalling as well as what hosts are up or down. You need to log outbound HTTP to be able to tell the difference. > > Another peculiar log which we would like to get more info on are > > > > Dec 23 18:43:05 theargonserver kernel: IPT IN_FIREWALL_NEW: IN=eth1 OUT= > > MAC=00:03:47:6a:5c:6b:00:c0:49:25:d1:a3:08:00 SRC=80.15.238.66 > > DST=xxx.xxx.xxx.xxx LEN=73 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=UDP > > SPT=31819 DPT=53 LEN=53 > > > > There are a lot of packets to port 53. Is this normal? > > Yes. UDP port 53 means client-to-server DNS lookups. It could also be server to server queries as well as a load balancer. See if you have an outbound query that immediately precedes this log entry. If so, its someone pulling metrics to see what IP to serve up to you. I'm leaning towards load balancer on this one as the source IP has no PTR. It could however be one of your users on their home account and their DNS entries are still pointed at the home office. BTW, if the above was a successful recursive query you really need to lock the box down. See the Bugtraq post I did back in Sept. on how spammers can park their domain on your recursive DNS. HTH, C
