[svlug] Firewalls?

Nick Austin nick at smartaustin.com
Wed Jan 24 17:26:52 PST 2007

I guess I should say before this long winded point by point rebuttal, that
I mostly agree with you Rick, but find some of your counter arguments suspect.

I think that moving the sshd port is useful from a technical and convenience
standpoint. I also think that being slightly different the the masses buys
you real protection against mass automated attacks.

There are real world examples of attacks that simply moving your sshd port
and/or using sshblack protect you against.

Example 1, knowledge leak caused by sshd taking a more expansive path
for a valid user then an invalid one. 

sshblack prevents this previously unknown attack. Moving the port prevents
the mass automated scrapping of usernames that ensued after the bug was

This could actually prevent a DoS, because there are so many of these running.

Example 2, Openssh buffer management bug. Remote code execution as user
sshd is running as. Immediately after exploit was in the wild, mass exploit
was ran by many people.

These scanned on _port 22_ at first. 

Sysadmin running sshd on port 8080 wakes up, and reads slashdot (or cnn), 
notes horrible new sshd problem, shuts off remote access/updates firewalls/
patches bug, etc.

The other sysadmin who was running on port 22 wakes up and starts intrusion

Like I said before, it may only buy you hours, or it might not buy you
anything at all. But the cost is essentially zero, so why not.

On Wed, Jan 24, 2007 at 12:57:52AM -0800, Rick Moen wrote:
> Hey, right on schedule, here come the gadget freaks!

You really do have me pegged on this. I really am a 100% gadget freak. :)
I guess that's why I'm in IT.

> Quoting Nick Austin (nick at smartaustin.com):
> > You can add the host parameters to your .ssh/config.
> All manner of kludges to compensate are possible. 

Well it seems like using the canonical config file to describe the hosts that
you're sshing in to is not really a kludge.

> However, you're rather ignoring my point.

I was just saying that this argument that you would be required to add an
additional flag to ssh and scp all the time is not really true.

> "Oh, if you hide _really well_, you can gain that extra two seconds' 
> lead in running away from the scary, nasty attack rabbit."

Sometimes, you only need two seconds to avoid the mass rooting, DoS,
or other badness. :)

> You know, frankly there are a lot more credible and serious threat
> models for me to spend my time and effort on.

This may be true, but if making a change is 2 mins of work that may save
you so much pain in the future, is it worth it?

I guess that's for everybody to decide on their own.

> > Also, if you change it to port 443, then you're more likely to be able
> > to connect to your ssh port though more proxies and firewalls.
> You could also make it put out a banner saying "I'm actually a Web
> server.  Please don't send me any ssh."  That would be at least equally
> time-wasting, but you could at least have fun doing it.

This would likely break clients, but I guess you might still have fun. :)

> (There _is_ actually some significant point in making your sshd respond
> on additional ports _alongside_ 22/tcp, as opposed to instead.  Mine
> responds on 23/tcp and 8080/tcp, for reasons that should be obvious.)

Why alongside? There is no reason to keep 22 is there?

Do you have old clients that are incapable of using a different port?
Does using config files really feel like a kludge?

I guess we're really splitting hairs here, you're correct that making this
change really only buys you a little extra. 

Still, from my point of view, it's a zero effort change that has both immediate
real and theoretical benefits.

As long as you don't get a false sense of security from it, you're fine.

> > If you're trying to defend against that attack, then an OTP (One Time
> > Password) solution is likely the best way to go.
> Strictly out of curiosity, have you ever actually _lived_ with having to
> do OPIE or S/Key?

I've used, and do use OTP. I keep a folded up card in my wallet that I use when
sshing in from hosts that might not be safe. Things like my friends WinXP 
desktops, etc.

It's not really that bad, except for having to print out a new list when
you run short on passwords.

> > Spoofing your IP source on an SSH login without access to the return 
> > traffic is impossible.
> You know:  You're going to look really foolish saying that if someone's
> compromised a nearby box or switch and is poisoning ARP tables.

If you have a nearby box or switch, then you have access to the return 

In this case it's easier to just RST all packets to the SSH port, you 
don't need sshblack to DoS a box like this.

> > It may be better then denyhosts, but it is not as good as a tool like
> > sshblack: http://www.pettingers.org/code/sshblack.html
> Frankly, looks like a real hairball implementation, relatively speaking.

This may be true, I've not looked at the code, but the idea is definitely

But you really might be better off using something like Spade to do your
dynamic blocking.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.svlug.org/archives/svlug/attachments/20070124/8cb7674f/attachment.bin

More information about the svlug mailing list