Re: Great IP Auto-Ban script

[David Desrosiers <daviddes@us.ibm.com>]

> First, the public machine you trust is not secure enough. 

In this case, it is... and MUCH more than necessary. That's why it remains 
public without much threat of being breached. Not only does this 
particular machine use public keys (not passwords), but there are several 
levels of access granted, depending on the particular user, time and 
account being used. Its not just a public-machine-with-sshd-running. 

Point taken, however. 

> If *your* machine requires that ssh and the strength of your password 
> not be trusted, how is it acceptable to trust another machine which 
> trusts both of those things?

Because I've been directly involved in the configuration of "both of those 
things" ;) Digital forensics and penetration analysis is a "professional 
hobby" of mine. 

> Presumably, the public machine also has more accounts, and thus more 
> potentially weak passwords.  Even if not, it's *still*  more 
> vulnerable, and open to attack which could eventually end up with
> something that logs keystrokes, allowing an attacker to get access to
> your machine.  It's like that "a chain's only as strong as its weakest
> link" thing...

I suppose they would be able to log the traffic that indicated a 
connection originated from $HOTEL to $TRUSTED_PUBLIC_MACHINE on port 22, 
but nothing more than that. I'm ok with giving up that level of security 
anyway, since no actual "data" is logged at all, at any of these levels. 

> Second, you're opening up a whole netblock for a period of time, instead
> of just one IP.  On the surface, opening up just the netblock that the
> hotel (and whoever else is a client of their ISP) sounds more safe than
> opening up to the whole Internet.

I'm ok with that, since I control my machines directly, and I've put some 
pretty aggressive controls in place to make sure I'm the only one who can 
get it. If someone can honestly brute-force my local login password, 
decrypt my home directory locally, get my public key and then connect to 
my remote machine all by sniffing "hotel traffic", they deserve to get 
in.. but getting in will just get them into a directory on a box. They 
won't have access to much from there, without knowing how to get to it, 
and what steps to take to open up those extra levels of access (not root). 


As they say, "This ain't your mother's Linux distribution". ;) 

> So, by opening up the whole hotel's block, you're actually opening up to 

> a set of IPs that are *more* likely to mount an attack.

I'm ok with that, since they'll be banging on port 22 for a looooooooooong 
time before they find something that will get them in, and by that time, 
I've already closed down the firewall rules and flown to my next 
destination. I've had this (or similar) setups for... going on 9 years 
now, and I have never yet (knock, knock on wood) been breached. Will it 
happen? Probably, but I'm pretty prepared for it in any case. 

> Then you don't have to permanently trust a machine
> that is less secure that yours, and you don't have that extra "what's my
> IP" step.  The port-knocking thing looks neat, too, but it's still
> potentially duplicatable by an informed man-in-the-middle ("huh, why all
> these connects with no data sent?")

You're making the assumption that the "public" machine is less secure than 
any other, but in this case that is not the case. Port-knocking is also 
well-tested, and not easy to subject to man-in-the-middle attacks as you 
assert, but if you have a valid case study that disproves the technology, 
I'm sure the project would love to hear about it. 

I'm not coming down on you specifically, or claiming that I have the 
Rosetta Stone in security, but doing P.A. for many years, I've seen lots 
of tricks by criminals who break into machines remotely, and I've 
incorporated countermeasures in my own processes and procedures for my 
business and personal LAN infrastructure. It builds over time. 

> Anyway, not to gripe - there's always *something* wrong with whatever
> security approach.  Just pointing things that are relevant to consider,
> and which some may not have thought about...

Precisely. Security is an ongoing process, not a program to install. I've 
learned and modified many of my own theories over the years as the 
technology and intelligence of the criminal mindset has advanced in 
lockstep. 


David A. Desrosiers
Linux on Power Developer Program Manager
daviddes@us.ibm.com


-
To unsubscribe, send email to majordomo@luci.org with
"unsubscribe luci-discuss" in the body.