On Sat, Apr 28, 2001 at 12:43:58AM +1000, Mark wrote: > I get packets (6) attempting to connect to me each time after running > fetchmail to get my mail from my ISP. I have no trouble getting the > mail. My firewall (iptables) silently drops these packets as it > recognises them as "new". > > Here are the relevant rules in my firewall: > iptables -N log_in_new > iptables -A log_in_new -j LOG --log-level 1 --log-prefix > "incoming_new_::" > iptables -A log_in_new -j DROP > > # 1. Allow us to initiate TCP connections to anywhere > iptables -A OUTPUT -o $EXT_IF -m state --state NEW,ESTABLISHED,RELATED > -j ACCEPT > > # 2. No INVALID packets > iptables -A INPUT -i $EXT_IF -m state --state INVALID -j log_invalid > > # 3. Allow only established and related packets to come in. This > includes: > # Related ICMP error messages, Packets establishing a FTP data > connection, > # and also the udp/tcp requests to DNS servers (udp/tcp port 53) > iptables -A INPUT -i $EXT_IF -m state --state ESTABLISHED,RELATED -j > ACCEPT > > # 4. No one allowed to connect to us > iptables -A INPUT -i $EXT_IF -m state --state NEW -j log_in_new > > Here is what is typically in my logs after fetching mail: > Apr 28 00:23:21 debian kernel: incoming_new_::IN=ppp0 OUT= MAC= > SRC=139.134.5.142 DST=61.9.158.250 LEN=40 TOS=0x00 PREC=0x00 TTL=120 > ID=62726 DF PROTO=TCP SPT=110 DPT=32831 WINDOW=8433 RES=0x00 ACK FIN > URGP=0 > > And this is typical of what I get after I send mail: > Apr 28 00:19:48 debian kernel: incoming_new_::IN=ppp0 OUT= MAC= > SRC=139.134.5.163 DST=61.9.158.250 LEN=65 TOS=0x00 PREC=0x00 TTL=120 > ID=29432 DF PROTO=TCP SPT=25 DPT=32826 WINDOW=7166 RES=0x00 ACK PSH FIN > URGP=0 > > Note, I use other ISPs also for mail retrieval and get none of this. > Does anyone know why my ISP would be trying to connect after the > fetchmail daemon has done its job? Is fetchmail just ending too soon > for it and thus the ISPs mail server is still thinking it is connected? > Note which flags are set on those packets? ACK FIN ... TCP requires 3-way-handshake setup and a 4-way close.
TCP close: FIN -> ACK <- ..These two often piggyback FIN <- ..with each other ACK -> You appear to send a FIN, then close the connection, your client apppears to not follow the relevant RFC(can't recall which ATM). Gordon Sadler
