Hy Frank, thank you for this suggestion. Can you explain which is the advantage in reseting the connection instead of simply dropping it?
----- Original Message ----- From: "Frank Huang" <[EMAIL PROTECTED]> To: "'Bruno Negr�o'" <[EMAIL PROTECTED]> Sent: Tuesday, January 15, 2002 11:34 AM Subject: RE: Help to analyze the pop3 protocol > Bruno: > I have following code in iptables rules, this might be more appropriate. > > # AUTH server > # Reject ident probes with a tcp reset > # Need to reset instead of drop for smtp, ftp, ssh and etc. > # > > $IPTABLES -A INPUT -i $WAN_IFACE -p tcp \ > --dport $AUTH -j REJECT --reject-with tcp-reset > > My suggestion is do not run any extra service on your firewall, such as > AUTH, if you do not have to do so. > > Frank Huang > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Bruno Negr�o > Sent: Monday, January 14, 2002 8:23 AM > To: Skough Axel U/IT-S > Cc: [EMAIL PROTECTED] > Subject: Re: Help to analyze the pop3 protocol > > > Thank you Axel and everybody. > > I found that my iptables INPUT chain does allow connections to the 113 port > (i didn't know it untill I check it now). > But I don't have any identd process running in my firewall to respond to the > auth request (this may be the reason of the reset response: "13:18:20.486787 > 15bis.etcetera.com.br.auth > falcon.etcetera.com.br.4475: R 0:0(0) ack > 3342539286 win 0 (DF)") > Do I need to install identd in my firewall in order to answer these > requests? > Does maintain a port opened without a process binded to it is a risk to the > firewall? > > > ----- Original Message ----- > From: "Skough Axel U/IT-S" <[EMAIL PROTECTED]> > To: "'Bruno Negr�o'" <[EMAIL PROTECTED]> > Sent: Monday, January 14, 2002 10:51 AM > Subject: RE: Help to analyze the pop3 protocol > > > Hello, > > The AUTH protocol is used by some servers on the Internet to verify the > connecting client. Your firewall should in general allow for incoming AUTH > requests as the server called may deny access when the client doesn't > confirm properly via the AUTH check. > In this case, when your POP3 client is masked behind the firwall using for > example NAT, the AUTH would be directed to the firewall rather than the POP3 > client. The firewall is then expected to respond. There is no need to > forward the AUTH call, but your firewall should be AUTH enabled. (TCP port > 113). > > Most commonly is to use the AUTH protocol for mail servers, not only POP3 > but also SMTP servers. The intention is that the sender should be possible > to check and thus that illegal or suspicious mail should be trackable even > when anonymous. Indeed, the purpose is to make it more difficult to send > truly anonymous mail. > > Hope this helps! > > Regards / Axel > > -----Original Message----- > From: Bruno Negr�o [mailto:[EMAIL PROTECTED]] > Sent: den 14 januari 2002 13:31 > To: [EMAIL PROTECTED] > Subject: Help to analyze the pop3 protocol > > > > Hy, i'm using a redhat linux with 2 ethernet interfaces and iptables + > ipmasquerading. > I made a tcpdump of a connection between a masqueraded client machine > (192.168.13.10) and my external pop3 server (falcon.etcetera). The > firewall's name is 15bis.etcetera.com.br > > What I found interesting was a connection originated from the pop3 server > to my client "auth" port. Does someone can explain what is this connection > made for and how it traverses my firewall? (does this new connection (auth) > have the state "RELATED"?) > > > 13:18:20.484479 15bis.etcetera.com.br.1257 > falcon.etcetera.com.br.pop3: S > 10873842:10873842(0) win 8192 <mss 1460,nop,nop,sackOK> (DF) > 13:18:20.484745 falcon.etcetera.com.br.pop3 > 192.168.13.10.1257: S > 3336463748:3336463748(0) ack 10873843 win 32120 <mss 1460,nop,nop,sackOK> > (DF) > 13:18:20.485471 15bis.etcetera.com.br.1257 > falcon.etcetera.com.br.pop3: . > ack 3336463749 win 8760 (DF) > 13:18:20.486676 falcon.etcetera.com.br.4475 > 15bis.etcetera.com.br.auth: S > 3342539285:3342539285(0) win 32120 <mss 1460,sackOK,timestamp 697211801 > 0,nop,wscale 0> (DF) > 13:18:20.486787 15bis.etcetera.com.br.auth > falcon.etcetera.com.br.4475: R > 0:0(0) ack 3342539286 win 0 (DF) > 13:18:20.488595 falcon.etcetera.com.br.pop3 > 192.168.13.10.1257: P > 1:40(39) ack 1 win 32120 (DF) > 13:18:20.491085 15bis.etcetera.com.br.1257 > falcon.etcetera.com.br.pop3: P > 0:29(29) ack 40 win 8721 (DF) > 13:18:20.491337 falcon.etcetera.com.br.pop3 > 192.168.13.10.1257: . ack 30 > win 32120 (DF) > 13:18:20.491405 falcon.etcetera.com.br.pop3 > 192.168.13.10.1257: P > 40:46(6) ack 30 win 32120 (DF) > 13:18:20.494094 15bis.etcetera.com.br.1257 > falcon.etcetera.com.br.pop3: P > 29:42(13) ack 46 win 8715 (DF) > 13:18:20.502936 falcon.etcetera.com.br.pop3 > 192.168.13.10.1257: P > 46:52(6) ack 43 win 32120 (DF) > 13:18:20.505369 15bis.etcetera.com.br.1257 > falcon.etcetera.com.br.pop3: P > 42:48(6) ack 52 win 8709 (DF) > 13:18:20.505645 falcon.etcetera.com.br.pop3 > 192.168.13.10.1257: P > 52:61(9) ack 49 win 32120 (DF) > 13:18:20.510062 15bis.etcetera.com.br.1257 > falcon.etcetera.com.br.pop3: P > 48:54(6) ack 61 win 8700 (DF) > 13:18:20.510286 falcon.etcetera.com.br.pop3 > 192.168.13.10.1257: P > 61:67(6) ack 55 win 32120 (DF) > 13:18:20.510478 falcon.etcetera.com.br.pop3 > 192.168.13.10.1257: F > 67:67(0) ack 55 win 32120 (DF) > 13:18:20.511021 15bis.etcetera.com.br.1257 > falcon.etcetera.com.br.pop3: . > ack 68 win 8694 (DF) > 13:18:20.512395 15bis.etcetera.com.br.1257 > falcon.etcetera.com.br.pop3: F > 54:54(0) ack 68 win 8694 (DF) > 13:18:20.512600 falcon.etcetera.com.br.pop3 > 192.168.13.10.1257: . ack 56 > win 32120 (DF) > _______________________________________________ > Firewalls mailing list > [EMAIL PROTECTED] > http://lists.gnac.net/mailman/listinfo/firewalls > > > _______________________________________________ > Firewalls mailing list > [EMAIL PROTECTED] > http://lists.gnac.net/mailman/listinfo/firewalls > > _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
