Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] DNS question about DNSENUM.PL



On 3/27/2013 4:00 PM, Rich Pieri wrote:
> --On Wednesday, March 27, 2013 3:28 PM -0400 Bill Horne 
> <bill at horne.net> wrote:
>
>> When combined with port-knocking, having a non-standard port for a
>> service like ssh is an effective means of preventing port-scanning 
>> attacks.
>> It doesn't prevent an ...
>
> It also makes you vulnerable to denial of service.

As does having a T-1 connection on local cables that anyone with a 
ladder can disrupt, or
having the vault alarm in a bank routed via a publicly-documented FM 
channel to a
well-known alarm center, or using UPS units that are only rated for the 
time it takes
to shut down your servers, or having a server room with an 
outside-facing window
that could be used to pour in gasoline, or renting a building with only 
plaster walls
between you and your co-tenants. There are a thousand ways to disrupt 
service,
but most corporate threat profiles can safely disregard them: the risk, 
at least with
the class of customer I deal with, is in having someone gain 
unauthorized access,
not in having someone unable to access the system for a legitimate purpose.

>
>> ... but [port-knocking and mapping] _IS_ an effective tool when 
>> properly deployed.
>
> I claim that obfuscation cannot be properly deployed. Obfuscation is 
> wrapping a towel around your head and pretending that if you can't see 
> the service then neither can anyone else.
>
> Changing the port isn't giving your neighbor the key to your home. 
> Keys are authentication tokens. The port is analogous to the keyway. 
> Changing the port is the same as moving the keyway. The lock is still 
> there and you still need the correct key; you've just moved it up or 
> down from where it is normally located which is usually a convenient 
> waist/elbow height.
>
> The only security that you've added is that blind thieves are going to 
> have a slightly harder time finding the keyway.

It's more like changing the lock to an unmarked housing that makes the 
lockpicker guess at
which manufacturer he's up against. As I wrote before, security is about 
delaying the
attacker until help can arrive, so if port-mapping and blocking is /all/ 
we do, then we're
going to fail: we've only slowed the attackers down. This is why most 
bank-vault
break-ins happen on weekends, since it takes more than sixteen hours to 
breach
a reinforced concrete barrier. It's also why banks don't keep as much 
cash in
their vaults on weekends, and why safe-deposit box holders are advised 
to purchase
insurance. It's /all/ about buying time: a $10 lock won't delay a thief 
long enough
for your neighbor to notice that there's someone next door, and being 
unwilling to
remove the system from /any/ chance of access will leave us vulnerable to
common-password attacks.

It is, of course, possible that the pool of black-hat expertise will 
become deep
enough that these measures are no longer worthwhile. We still have to 
consider
the threat model against available safeguards, and the cost of implementing
them. Telling ssh users to click on an icon, instead of opening the ssh 
client
themselves, is one of those costs.

Security is an arms race. If you have a defense that makes all potential 
attackers
think they lose by attacking you, then you win by default. Making your 
house
harder to break into than your neighbor's isn't security by obscurity: 
it's just the
first step you take to protect your house against a targeted attack. 
There are,
of course, other steps, and each must be evaluated in terms of the time
it takes an attacker to overcome them.

Bill

-- 
Bill Horne
339-364-8487




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org