Date: Sat, 7 Nov 1998 03:04:39 -0800 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Guido van Rooij <guido@gvr.org>, "Jan B. Koum " <jkb@best.com>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Nate Williams <nate@mt.sri.com> Cc: Don Lewis <Don.Lewis@tsc.tdk.com>, cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/usr.sbin/inetd inetd.c Message-ID: <199811071104.DAA20558@salsa.gv.tsc.tdk.com> In-Reply-To: Guido van Rooij <guido@gvr.org> "Re: cvs commit: src/usr.sbin/inetd inetd.c" (Nov 5, 7:27pm)
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 5, 7:27pm, Guido van Rooij wrote: } Subject: Re: cvs commit: src/usr.sbin/inetd inetd.c } I have some more patches. Somehow I dont get replies back on review requests. } } Can someone bless the followings: } } -Guido } } >From: Darren Reed <avalon@COOMBS.ANU.EDU.AU> } Subject: Making "stealth" scans harder. } } The below patch helps to reduce the leakage of internal socket information } when a TCP "stealth" scan is directed at a *BSD box by ensuring the window } is 0 for all RST packets generated through tcp_respond(). Patch is against } NetBSD-1.3G but should apply to others with some fuzz. [snip] Looks ok to me. } The following also seems like a good idea (of course the FreeBSD } cocde is entirely different). However I'm concearned about the RFC. } } It states: } } Reset Generation } } As a general rule, reset (RST) must be sent whenever a segment arrives } which apparently is not intended for the current connection. A reset } must not be sent if it is not clear that this is the case. } } There are three groups of states: [ snip ] } 2. If the connection is in any non-synchronized state (LISTEN, } SYN-SENT, SYN-RECEIVED), and the incoming segment acknowledges } something not yet sent (the segment carries an unacceptable ACK), or } if an incoming segment has a security level or compartment which } does not exactly match the level and compartment requested for the } connection, a reset is sent. } } If our SYN has not been acknowledged and the precedence level of the } incoming segment is higher than the precedence level requested then } either raise the local precedence level (if allowed by the user and } the system) or send a reset; or if the precedence level of the } incoming segment is lower than the precedence level requested then } continue as if the precedence matched exactly (if the remote TCP } cannot raise the precedence level to match ours this will be } detected in the next segment it sends, and the connection will be } terminated then). If our SYN has been acknowledged (perhaps in this } incoming segment) the precedence level of the incoming segment must } match the local precedence level exactly, if it does not a reset } must be sent. } } If the incoming segment has an ACK field, the reset takes its } sequence number from the ACK field of the segment, otherwise the } reset has sequence number zero and the ACK field is set to the sum } of the sequence number and segment length of the incoming segment. } The connection remains in the same state. [ snip ] } } It does not ay anything on what to do when a FIN is sent to a socket } in LISTEN state. However, when receiving such a FIN when in LISTEN state, } it is clear that a segment arrives that apparently is not intended for } the current connection and thus it should be acceptable to send an RST in } this case. Perhaps an omission in the RFC? If the segment has the ACK bit set, then rule 2 above says that a RST should be sent. If the segment only has the FIN bit set, then I don't think it is safe to sent a RST. This could break T/TCP if the incoming request is broken into two segments and they arrive out of order. It may be possible to tighten down the conditions at some increase in code complexity. It's been a while since I looked at this stuff, though. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811071104.DAA20558>