Date: Wed, 30 May 2001 01:28:30 +0200 From: "Liran Dahan" <lirandb@netvision.net.il> To: <freebsd-security@freebsd.org> Subject: Re: Syn+Fin (Setup) And TCP RST Message-ID: <000801c0e897$11f2bb80$b88f39d5@a> References: <010f01c0e888$5ab3c120$b88f39d5@a> <200105291052100670.246E525C@smtp> <012601c0e88c$3e6efb20$b88f39d5@a> <3B141E8A.5AC7E84E@globalstar.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I checked the rules order, its ok...But something strange.. I've added rule like: ipfw add 1 reset tcp from any to any 100-200 , and i have daemon running on port 110, i telneted it and i got connection refused after 2 secs..(even when i have TCP_RESTRICT_RST Enabled - Via sysctl and Kernel), But when i telneted the other ports (that arent running daemons - Closed ports), it took about 30 seconds till i got connection refused - or it was connection timeout (i did it from windows telnet). Though if i add rule like ipfw add ip from any to any, ill get connection refused after 2 secs (As if TCP_RESTRICT_RST Is disabled) And about the TCP_RESTRICT_RST, You right, it has nothing to do with it. -Liran Dahan- (lirandb@netvision.net.il) ----- Original Message ----- From: "Crist Clark" <crist.clark@globalstar.com> To: "Liran Dahan" <lirandb@netvision.net.il> Cc: <freebsd-security@FreeBSD.ORG> Sent: Wednesday, May 30, 2001 12:11 AM Subject: Re: Syn+Fin (Setup) And TCP RST > Liran Dahan wrote: > > > > Yes, you right, i noticed it just now, i've changed the variable > > net.inet.tcp.restrict_rst to 1 and saw it took me ages till i got Connection > > timeout.. so what can be the problem.. why my firewall is not sending TCP > > RST when im doing ipfw add reset tcp from any to any ? > > The output of, > > # ipfw show > # tcpdump -nv 'host <host_you_telnet_from>' > <do the telnet test from the testing host> > # ipfw show > > Yes, two 'ipfw show's to see if we can see the packets being counted in > another rule. Perhaps add some logging. We want to be _sure_ that the > connection attempts are actually triggering the rule with the 'reset' > action before jumping to conclusions about no RSTs. > > I would be surprised if TCP_RESTRICT_RST is interfering with this. IIRC, > the code for "spoofing" these RSTs in the firewall lives in other parts > of the kernel from that generating "real" RSTs (where TCP_RESTRICT_RST > would have its effects). > -- > Crist J. Clark Network Security Engineer > crist.clark@globalstar.com Globalstar, L.P. > (408) 933-4387 FAX: (408) 933-4926 > > The information contained in this e-mail message is confidential, > intended only for the use of the individual or entity named above. If > the reader of this e-mail is not the intended recipient, or the employee > or agent responsible to deliver it to the intended recipient, you are > hereby notified that any review, dissemination, distribution or copying > of this communication is strictly prohibited. If you have received this > e-mail in error, please contact postmaster@globalstar.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000801c0e897$11f2bb80$b88f39d5>