[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Great IP Auto-Ban script
> 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
David A. Desrosiers
Linux on Power Developer Program Manager
To unsubscribe, send email to firstname.lastname@example.org with
"unsubscribe luci-discuss" in the body.