From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 52ABC21F0F0 for ; Fri, 17 Jan 2014 15:24:22 -0800 (PST) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id s0HNO2xf016243; Fri, 17 Jan 2014 15:24:02 -0800 Date: Fri, 17 Jan 2014 15:24:02 -0800 (PST) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Dave Taht In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] improving security: xinetd X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 23:24:38 -0000 On Thu, 16 Jan 2014, Dave Taht wrote: > in terms of a stable release, improving security some more has been > weighing on my mind. > > One of the things cero does differently than openwrt > is that it uses the xinetd daemon. It rather than having things like dropbear > or rsync listening directly on ports, and specifically only allows access > to certain services (like ssh) from certain ip addresses. > > There are also sensors for connection attempts via ftp or telnet that > disable all services when someone accesses them, for 120 minutes by > default. this seems like something that's unreasonable to do on something exposed to the Internet. There's a very real probability that this will result in you being unable to access your router because it's always in this 'lockdown' mode. I don't object to the capability being there, but I do object to it being on by default, especially for such a long lockout period. If you make the lockout per-IP then it may be reasonable, but this could result in a lot of IPs in your block list. David Lang > See the /etc/xinetd.conf and /etc/xinetd.d dir for details > > However this layer of defense is incomplete as several processes, notably the > configuration gui, upnp, and so on are separate daemons with their own > access controls. Worse, many attacks nowadays come from the inside, > and should be dealt with... > > Since we've been fiddling with ipsets on the bcp38 front it would be > rather easy to hook up xinetd's mechanism with that to do the same > blocking for *all* services from that specific IP. All it needs is a > fork and exec in the sensor to run a script like this: > > #!/bin/sh > # $1 = addr type (ipv4 or ipv6) > # $2 = addr > # $3 = timeout in seconds > > ipset add badboys-$1 $1 timeout $3 > > ... > > and use the firewall rules to check that ipset for badboy IPs. > > the xinetd.org site is dead seemingly, but copies of the last release > are widely available. Would probably be a very small patch if someone > wants to > take it on... > > is there anything else out there as tight and secure as xinetd for > spawning network services or doing intrusion monitoring? > >