full-disclosure - OpenSSH is a good choice?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

From: dk at pwarchitects.com (dk)
Subject: OpenSSH is a good choice?

Willem Koenings wrote:
> On Wed, 22 Dec 2004 02:40:25 -0600 (CST), Ron DuFresne
> <dufresne@...ternet.com> wrote:
> 
> 
>>I'd disagree in that the tools are getting to be well enough defined that
>>we are all targets.  Best game is to restrict who has access to the ports
>>being served whenever possible, openssh has a history that makes this a
>>good service to limit this way.  Little need to hide what's not openly
>>allowed to all.
> 
> take a recent phpBB worm Santy for an example. worm seaches
> automatically targets via google - it searches
> viewtopic.php. if, for an example, you change that file name to
> something else (and also all the referrings inside the phpBB so that
> everything still works), then Santy does not find you phpBB as a
> target. this is only an illustration to my point.

(Hi there. sorry for butting in.)

This concept does work for a little bit... As it is exactly what I did: 
using the same highlight hole to rename viewtopic.php to viewtopic1.php 
for a friend who was unreachable during the worms first hit. But it also 
took me only a few minutes messing with the query that the worm used to 
mod it to make /some/ schemes like this into account on the next google 
indexing - and my current perl 5killz are not uber. ;-/
I just mention it because non-std mods to anything can breed a different 
sort of complacently. In the end it's the same ole' game I guess.

> i wrote my post because you say "the non std port advice is not worth
> much". i have lot of cases, when non standard configuration reduces
> first impact greatly. of course you shouldn't rely only to non
> standard ports/configuration, but it is not totally worthless - it
> often helps you a lot.

I too agree that it's not worthless for certain usages, especially as 
you mention: on first impact. But depending on context it _can_ create 
more burden on the admin later when you must recall what non-standard 
changes /you/ made to the application or source package when upgrade 
time comes around. Files may not be patched/removed due to name changes 
and could be left available for future exploits. These custom changes 
may also open you to other issues in the future... like putting ssh on a 
high port that turns into a popular p2p port in a years time and it 
hammers your logs or some such. <shrug>

Anyway - In this specific case, if the OP wanted to further restrict ssh 
from pre-auth bugs a system like fwknop[1] or SAdoor[2] would work 
better to open the std port 22 (or what ever) than simple port knocking.

[1] http://www.cipherdyne.org/fwknop/
[2] http://cmn.listprojects.darklab.org/