[clug] mc-root anyone?

Kim Holburn kim at holburn.net
Fri Jun 19 20:27:19 GMT 2009


On 2009/Jun/19, at 12:57 PM, Michael Cohen wrote:

> On Fri, Jun 19, 2009 at 6:19 PM, Kim Holburn<kim at holburn.net> wrote:
>> I've used ipt_recent and there are probably userland targets or you  
>> can use
>> scripts.
>
> ipt_recent simply limits frequently connecting hosts. If there is a
> vuln in SSH you only need a single connection to be done over.

You can do interesting things with ipt_recent.  I set up a port knock  
system with it a long time ago, before I had heard the term "port  
knock".  The whole thing happened in netfilter.  It's complicated but  
doable.

Bear in mind this is a fragment.  There are assumptions, maybe not all  
specified and maybe not all relevant to a single server.

To knock you have to hit these ports in this order:
IP.OF.SERVER1:1111
IP.OF.SERVER3:3333
IP.OF.SERVER2:2222


LOG='-j LOG --log-level info --log-prefix'


$IPTABLES -N GOOD
$IPTABLES -A GOOD $LOG 'GOOD '
$IPTABLES -A GOOD -m recent --name GOOD --remove
$IPTABLES -A GOOD -j ACCEPT

$IPTABLES -N NOTGOOD
$IPTABLES -A NOTGOOD -m recent --name GOOD --hitcount 0 --rcheck $LOG  
'NOTG0 '
$IPTABLES -A NOTGOOD -m recent --name GOOD --hitcount 1 --rcheck $LOG  
'NOTG1 '
$IPTABLES -A NOTGOOD -m recent --name GOOD --hitcount 2 --rcheck $LOG  
'NOTG2 '
$IPTABLES -A NOTGOOD -m recent --name GOOD --hitcount 3 --rcheck $LOG  
'NOTG3 '
$IPTABLES -A NOTGOOD -m recent --name GOOD --hitcount 4 --rcheck $LOG  
'NOTG4 '
$IPTABLES -A NOTGOOD $LOG 'NOTGOOD '
$IPTABLES -A NOTGOOD -m recent --name GOOD --remove
$IPTABLES -A NOTGOOD -j THEDROP

$IPTABLES -N MAYBE1
$IPTABLES -A MAYBE1 -m recent --name GOOD --hitcount 2 --rcheck -j  
NOTGOOD
$IPTABLES -A MAYBE1 -m recent --name GOOD --update $LOG 'MAYBE1 '
$IPTABLES -A MAYBE1 -j ACCEPT

$IPTABLES -N MAYBE2
$IPTABLES -A MAYBE2 -m recent --name GOOD --hitcount 3 --rcheck -j  
NOTGOOD
$IPTABLES -A MAYBE2 -j GOOD

$IPTABLES -N MAYBE
$IPTABLES -A MAYBE -d IP.OF.SERVER3 -p tcp --dport 3333 -j MAYBE1
$IPTABLES -A MAYBE -d IP.OF.SERVER2 -p tcp --dport 2222 -j MAYBE2
$IPTABLES -A MAYBE -p ! icmp -j NOTGOOD
$IPTABLES -A MAYBE -j DROP

$IPTABLES -N PERHAPS
$IPTABLES -A PERHAPS $LOG 'PERHAPS '
$IPTABLES -A PERHAPS -m recent --name GOOD --set -j ACCEPT

$IPTABLES -N 1stDROP
$IPTABLES -A 1stDROP -m recent --name GOOD --rcheck -j MAYBE
$IPTABLES -A 1stDROP -d IP.OF.SERVER1 -p tcp --dport 1111 -j PERHAPS
$IPTABLES -A 1stDROP -j DROP




>> But all that action happens in the clear and is interruptible and  
>> duplicable
>> by a listener ie an MITM attack.
>
> Indeed - but for an attacker to see the knock sequence they need to be
> in the path of communication to intercept it - not entirely impossible
> but certainly beyond the reach of most russian hackers.  This is why
> its a medium level of security for a front line defence mechanism.
>
>> And it's been thought through and tested for security by experts.
>
> Indeed - but it is still a complex protocol. You do recall the whole
> openssl key fiasco a couple of months ago. Because my servers were
> behind port knocks they were immune from opportunistic zero day
> attacks until I can patch them. Security is a process - nothing is
> full proof. Port knocks are an additional, easy to implement, security
> layer and they can only add to the overall security by raising the bar
> for an attacker to even launch an attack. The overall trade off is
> very favourable - its only slightly inconvenient for users.
>
>> It might make you feel more secure.
>>
>> Take out passwords and use RSA keys, it's built-in to ssh.  It  
>> can't be
>> attacked like passwords and it's "very" secure, to quite large  
>> values of
>> "very".
>
> Yep - no problem with that. Except when keys arent quite random, or
> buffers are too small or some other unforeseen problems occur.
>
>> It's also easy to break a well constructed security system by  
>> adding stuff
>> the original authors never thought you would and it's happened with  
>> ssh
>> several times.  The startup protocols are critical to setting up ssh
>> securely.  Be careful.
>
> Yep - knocking has nothing to do with ssh - it simply adds iptable
> rules to allow a single connection.  The subsequent ssh connection is
> not interfered with in any way. Although, you are kind of making the
> assumption that the ip address the knocks come from is the same as the
> address the ssh connection come from (might be wrong if you are behind
> a NAT that uses a pool of addresses) so its not perfect.
>
> I believe that knocking is best practice and always set my servers
> like that. I have not come across many other admins that do - maybe im
> more paranoid about it.
>
> Michael.

-- 
Kim Holburn
IT Network & Security Consultant
Ph: +39 06 855 4294  M: +39 3494957443
mailto:kim at holburn.net  aim://kimholburn
skype://kholburn - PGP Public Key on request








More information about the linux mailing list