From owner-freebsd-questions@freebsd.org Mon Jul 26 13:36:50 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 12D1066C5F1 for ; Mon, 26 Jul 2021 13:36:50 +0000 (UTC) (envelope-from freebsd@qeng-ho.org) Received: from mailout.qeng-ho.org (mailout.qeng-ho.org [217.155.128.244]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GYLYs02SMz4bVl for ; Mon, 26 Jul 2021 13:36:48 +0000 (UTC) (envelope-from freebsd@qeng-ho.org) Received: from arthur.home.qeng-ho.org (unknown [IPv6:2a02:8010:64c9:1::2]) by mailout.qeng-ho.org (Postfix) with ESMTP id E4D2D50D9C; Mon, 26 Jul 2021 14:36:32 +0100 (BST) Subject: Re: Detecting or mitigating syn-flood attacks To: Norman Gray , FreeBSD Questions References: <57893A91-2180-441F-836F-66EAC526FBB8@nxg.name> From: Arthur Chance Message-ID: Date: Mon, 26 Jul 2021 14:36:32 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <57893A91-2180-441F-836F-66EAC526FBB8@nxg.name> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4GYLYs02SMz4bVl X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@qeng-ho.org designates 217.155.128.244 as permitted sender) smtp.mailfrom=freebsd@qeng-ho.org X-Spamd-Result: default: False [0.70 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:217.155.128.240/29]; NEURAL_SPAM_SHORT(1.00)[1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[qeng-ho.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:13037, ipnet:217.155.0.0/16, country:GB]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[freebsd-questions]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2021 13:36:50 -0000 On 26/07/2021 13:59, Norman Gray wrote: > > Greetings. > > Can anyone point me towards best-practice guidance on detecting and > mitigating syn-flood attacks, with a focus on FreeBSD? > > We run a login server, providing ssh access to our users, from the open > internet.   It's running in a jail on a FreeBSD machine.  This machine > (both jail and host) has recently become unresponsive on occasion, even > to the extent of it being impossible to log in on the console (the > password prompt never appears).  Nothing in the logs.  We _think_ we are > (or have been) victim to a syn-flood attack, but mostly on the grounds > of having ruled out most plausible alternatives: we're struggling to > find positive confirmation of this. > > So I have two related questions: > > 1. What should we be looking at, to confirm or refute this hypothesis?  > And, supposing that the attack has stopped when we're looking, what > should we be monitoring to detect such a thing if it comes back? This is theoretical, I have no personal experience, but you might want to look at the net.inet.tcp.syncache MIB tree. sysctl -d net.inet.tcp.syncache for quick descriptions. net.inet.tcp.syncache.count would seem to be the first thing to watch, and tweaking net.inet.tcp.syncache.cachelimit or net.inet.tcp.syncookies_only might help, but I'd wait until someone more knowledgable than me chips in. > 2. Is there a best practice document that we should be working through?  > The machine is in a jail, with firewall rules which are, I _think_, as > restrictive as is compatible with the service's purpose of having port > 22 open to the internet. > > A few extra observations: > > I thought I'd be able to find all sorts of information and guidance on > this, but my google-fu seems lacking. > > Regarding the sshd configuration, > makes a > few points, which we're already observing.  The machine's sshd_config is > pretty restrictive: I'm reasonably comfortable I understand the > important parts of the sshd configuration, but there's always more to > learn.  In any case, my own uncertainty is more with the pf > configuration than the sshd one. > > I see for example > , > but that's rather terse, and now 10 years old. > > There are of course various 'top 20 ssh best practices !1!!' documents > here and there, but their recommendations, while not necessarily wrong, > tend to be rather voodoo, which doesn't make me trust them much. > > I'm comfortable with basic pf configuration, but I haven't so far had to > venture very far off-shore.  I'm reluctant to type in firewall rules I > don't understand (*cough*). > > I'm also using blacklistd on the jail host, with all its eccentricities -- Nothing teaches one not to try to stamp out burning thermite quite like real-life experience. — James Davis Nicoll