From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (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 291ED21F159 for ; Thu, 16 Jan 2014 17:22:09 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id t60so3869941wes.23 for ; Thu, 16 Jan 2014 17:22:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=k7BIkC7ro4k7z9WfrQ4NMdFJmcV665SvEyOlZGpfPC0=; b=FaRFfe8CR+IeKFZwlBbxD1zlUSaJGgsLqI+XaXoKPfn8K8kTroRUdplVCxWoesFzxn XAWAoAuhM1658gF/MEJMWJYyI6vkf8FViCKshEC7LlZGRoRVSRF/+TMundmVNLpNejI2 UFXptNcPy8ZV2Ur5RBeA2dF5JZZZnlYLWCGds1qqxYJnJUOGlJC0RifpYSI9QZBlVvct B9NP0tWJ2FUZ9bxJnaBEwJauvsw7qlgGuupbGEOemUeKwAFvJSJlzaHPUzAroW6AUg3C xzsbMvfdFfyh3SwndYIhP4WDWyuve4KJJnBWvelHxp5Lg9kePsyrFhNY0lrGGjzt99Fw vUzQ== MIME-Version: 1.0 X-Received: by 10.180.76.42 with SMTP id h10mr108601wiw.46.1389921727994; Thu, 16 Jan 2014 17:22:07 -0800 (PST) Received: by 10.217.123.69 with HTTP; Thu, 16 Jan 2014 17:22:07 -0800 (PST) Date: Thu, 16 Jan 2014 20:22:07 -0500 Message-ID: From: Dave Taht To: "cerowrt-devel@lists.bufferbloat.net" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [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 01:22:16 -0000 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 dropbe= ar 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. See the /etc/xinetd.conf and /etc/xinetd.d dir for details However this layer of defense is incomplete as several processes, notably t= he 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