From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 8EBBA21F0F0 for ; Fri, 17 Jan 2014 15:29:53 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id w62so5228720wes.27 for ; Fri, 17 Jan 2014 15:29:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=e+OUQce88NON213+nd23Yn8xUQkqODSVNmb8eaqkm48=; b=r4w4pm6ErWObgS+s3+6Owr1TF785ByJM2cXVJWhTCO2mpCtyON7Pxz2dEwx8GSIsqd E/hnJ64ktzeOYkB/eTDTsWp3ZIcLlhR+Pfzz1x1itSPEARHyDwL+iJ4S4Za0GfipkRfk ke5YtXi6z0MRsRLSpGL0oGb60EX41HbFI7sSP9zJ6JYYibcrEkKwd4AIDrthtkoiYU0p n5OvuIOth0jbue9tLiB1gEsuw8zAfnIahhp9hr0n6fL50FmflXaSYC0niuk9XoATgd/V wuaWZ+v9QfjrBXyiKXaJ/dKmKnHszHzAh0H+abnRTvvnjiCXtq0ezuRAwV2VeQ3BTc0j VPiw== MIME-Version: 1.0 X-Received: by 10.180.95.162 with SMTP id dl2mr596999wib.17.1390001391889; Fri, 17 Jan 2014 15:29:51 -0800 (PST) Received: by 10.217.123.69 with HTTP; Fri, 17 Jan 2014 15:29:51 -0800 (PST) In-Reply-To: References: Date: Fri, 17 Jan 2014 18:29:51 -0500 Message-ID: From: Dave Taht To: David Lang Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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:30:00 -0000 On Fri, Jan 17, 2014 at 6:24 PM, David Lang wrote: > 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 acces= s >> 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 yo= u > 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. Heh. These sensors have been on by default in cero for ~2 years. Trigger th= em? I should have qualified the sentence: disable all services to that IP when that IP accesses them, for 120 minutes= by default. > 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. it has always been per IP, and thus far, one of the techniques that just silently "works". As an increasing number of attacks are coming from inside the fire= wall I'd like to extend this feature to include blocking all services. It would be even more useful if it could redirect offenders to a web page telling them that = their device is doing something bad... Also the number of DNS driveby attempts at finding open relays is enormous and I wouldn't mind blocking those, logging them, and shipping the results up to appropriate authorities... > > David Lang > > >> See the /etc/xinetd.conf and /etc/xinetd.d dir for details >> >> However this layer of defense is incomplete as several processes, notabl= y >> 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 =3D addr type (ipv4 or ipv6) >> # $2 =3D addr >> # $3 =3D 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? >> >> > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html