From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 878DD1381F3 for ; Sun, 13 Oct 2013 16:37:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 53D1EE09E4; Sun, 13 Oct 2013 16:37:15 +0000 (UTC) Received: from mail2.viabit.com (mail2.viabit.com [65.246.80.16]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 2F37EE09C9 for ; Sun, 13 Oct 2013 16:37:14 +0000 (UTC) Received: from [172.17.29.6] (vpn1.metro-data.com [65.213.236.242]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail2.viabit.com (Postfix) with ESMTPSA id 3cyT893NJlz1hgC for ; Sun, 13 Oct 2013 12:37:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=orlitzky.com; s=mail2; t=1381682233; bh=GXx/HyJMVrB8IYcJ+E5c+yQTbbNmm5NmqiS4Hr+OIXU=; h=Date:From:To:Subject:References:In-Reply-To; b=cUB1X6vwYewoVDrBgKTS+9BN4x6wKjNaD96R3P/r0rGxnPXXwpG5j958ifX41G32U ydzd9O2jxYa4me9gUEvG6U9KXERQZDYI8FsqU+W0xDDqRZx1/CIrTqip4s5SrXyRFs jayynDtbEvTJnaFzZdKUX5jw2q/1x52At3EUK4o4= Message-ID: <525ACC38.8060008@orlitzky.com> Date: Sun, 13 Oct 2013 12:37:12 -0400 From: Michael Orlitzky User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130929 Thunderbird/17.0.9 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: scripted iptables-restore References: <524DD388.9020507@fastmail.co.uk> <524F39F6.4040409@orlitzky.com> <525AAADE.7040700@orlitzky.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 1d59cbdb-7f23-488b-a45a-3f268ddc11a9 X-Archives-Hash: 4e215d4f011500bbb35521af5cc56b7f On 10/13/2013 11:19 AM, Martin Vaeth wrote: >>> >> [...] >> If you have a million rules and you need to wipe/reload them all >> frequently you're probably doing something wrong to begin with. > > I don't know how this is related with the discussion. > The main advantage of using iptables-restore is avoidance of > race conditions. A secondary advantage is a speed improvement; > in my case, the machine boots about 2 seconds faster which can > be a considerable advantage if you start virtual machines. > I was just reiterating that there's not much benefit to save/restore if you're doing things properly (pontification alert!). I should say first of all that save/restore is perfect for reboots. If you're not *changing* anything, of course save/restore is better, and suffers none of the problems that I mentioned: you don't read it, the output is fed directly as input, no errors should occur... The bash script is used a couple times a year, and really is there to serve as the specification for what your firewall should do. For example, I'm rebuilding our MX today. I checked the config out of git, ran iptables-config (our script), ran /etc/init.d/iptables save, and the firewall is up and running. When will I run the script again? The next time I rebuild the server? That's certainly the last time I ran it. We have firewalls that change more often, but not so frequently that the speed would be a problem if it were 1000x slower. The MX firewall is actually updated many times per day and accumulates many rules, but they're inserted/deleted in-place by fail2ban, so a full wipe/reload doesn't occur. If you have frequently-changing permanent rules -- say, lots of static NAT entries going in/out for new employees -- then you should be doing insert/delete instead of a full reload just the same. But, add the rule to your iptables script (with a comment!) so that you have it on the record. Once every six months or so, run the thing to make sure nobody made a copy/paste error. Race conditions don't really seem that serious to me. Of course, if you're using iptables for both authorization and authentication, then you're already doing something wrong, and you should fix that instead of trying to make the broken thing run faster. But if not, who cares if you're vulnerable to a brute force attack for 2 seconds? If you're worried about that, implement a password policy. The firewall is the last layer of defense-in-depth; if the absence of a firewall gives you nightmares, the absence of a firewall is not your problem. All of security is a trade-off, and in my opinion, having human-friendly, easily-readable rules (with error checking) will prevent more problems over time than does eliminating the race condition.