From owner-cvs-all Thu Nov 5 10:32:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA11294 for cvs-all-outgoing; Thu, 5 Nov 1998 10:32:18 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from gvr.gvr.org (gvr.gvr.org [194.151.74.97]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA11289 for ; Thu, 5 Nov 1998 10:32:14 -0800 (PST) (envelope-from guido@gvr.org) Received: (from guido@localhost) by gvr.gvr.org (8.8.8/8.8.5) id TAA18861; Thu, 5 Nov 1998 19:27:40 +0100 (MET) Message-ID: <19981105192740.A18801@gvr.org> Date: Thu, 5 Nov 1998 19:27:40 +0100 From: Guido van Rooij To: "Jan B. Koum " , Poul-Henning Kamp , Nate Williams Cc: Don Lewis , cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/usr.sbin/inetd inetd.c References: <199811050756.AAA17272@mt.sri.com> <11223.910253625@critter.freebsd.dk> <19981105002852.B18743@best.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <19981105002852.B18743@best.com>; from Jan B. Koum on Thu, Nov 05, 1998 at 12:28:52AM -0800 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk On Thu, Nov 05, 1998 at 12:28:52AM -0800, Jan B. Koum wrote: > On Thu, Nov 05, 1998 at 09:13:45AM +0100, Poul-Henning Kamp wrote: > > Most portscans these days won't get logged with that sysctl setting. > Reason is that they don't always have TH_SYN only - in many case > they don't even have that. > Here is for example what nmap portscanner can do: > > -sT tcp connect() port scan > -sS tcp SYN stealth port scan (must be root) > -sF,-sX, -sN Stealth FIN, Xmas, or Null scan (only works against UNIX). > > Going from TH_SYN to TH_FLAGS in tcp_input.c will solve that. > Maybe I should beautify www.best.com/~jkb/tcp_input.diff.txt and > just send-pr it? I have some more patches. Somehow I dont get replies back on review requests. Can someone bless the followings: -Guido >From: Darren Reed 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. Cheers, Darren *** tcp_subr.c.orig Sun Aug 2 21:16:42 1998 --- tcp_subr.c Thu Sep 17 22:38:51 1998 *************** *** 214,220 **** struct route *ro = 0; if (tp) { ! win = sbspace(&tp->t_inpcb->inp_socket->so_rcv); ro = &tp->t_inpcb->inp_route; } if (m == 0) { --- 214,221 ---- struct route *ro = 0; if (tp) { ! if (!(flags & TH_RST)) ! win = sbspace(&tp->t_inpcb->inp_socket->so_rcv); ro = &tp->t_inpcb->inp_route; } if (m == 0) { *************** *** 247,253 **** ti->ti_ack = htonl(ack); ti->ti_x2 = 0; if ((flags & TH_SYN) == 0) { ! if (tp) ti->ti_win = htons((u_int16_t) (win >> tp->rcv_scale)); else ti->ti_win = htons((u_int16_t)win); --- 248,254 ---- ti->ti_ack = htonl(ack); ti->ti_x2 = 0; if ((flags & TH_SYN) == 0) { ! if (tp && !(flags & TH_RST)) ti->ti_win = htons((u_int16_t) (win >> tp->rcv_scale)); else ti->ti_win = 0; 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: 1. If the connection does not exist (CLOSED) then a reset is sent in response to any incoming segment except another reset. In particular, SYNs addressed to a non-existent connection are rejected by this means. 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 CLOSED state. 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. 3. If the connection is in a synchronized state (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), any unacceptable segment (out of window sequence number or unacceptible acknowledgment number) must elicit only an empty acknowledgment segment containing the current send-sequence number and an acknowledgment indicating the next sequence number expected to be received, and the connection remains in the same state. If an incoming segment has a security level, or compartment, or precedence which does not exactly match the level, and compartment, and precedence requested for the connection,a reset is sent and connection goes to the CLOSED state. The reset takes its sequence number from the ACK field of the incoming segment. 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? >From: Darren Reed Subject: stopping "nack" `stealth' scanning. One of the other ways to stealth scan is observing which ports no reply is received for. This patch causes RST's to be generated when sending (for example) a FIN to a listening socket, the same as in all other occasions. Patch provided by mycroft. Darren *** tcp_input.c.orig Sat Sep 19 14:52:06 1998 --- tcp_input.c Sat Sep 19 14:24:22 1998 *************** *** 618,624 **** tiwin <<= tp->snd_scale; goto after_listen; } ! } } else { /* * Received a SYN. --- 618,625 ---- tiwin <<= tp->snd_scale; goto after_listen; } ! } else ! goto badsyn; } else { /* * Received a SYN. --3uo+9/B/ebqu+fSQ-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message