[Cerowrt-devel] improving security: xinetd

[Cerowrt-devel] improving security: xinetd

[Dave Taht]

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.

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?

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] improving security: xinetd

[David Lang]

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?
>
>

Re: [Cerowrt-devel] improving security: xinetd

[Dave Taht]

On Fri, Jan 17, 2014 at 6:24 PM, David Lang <david@lang.hm> 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 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.

Heh. These sensors have been on by default in cero for ~2 years. Trigger them?

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 firewall
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, 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?
>>
>>
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html