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: dufresne at winternet.com (Ron DuFresne)
Subject: OpenSSH is a good choice?

On Fri, 24 Dec 2004, Ben Hawkes wrote:

> On Thu, Dec 23, 2004 at 12:43:31AM -0600, Ron DuFresne wrote:
> > My thoughts on this have centered on the point that there are too many
> > decent scanning and banner grabbing tools out there to make botuse port
> > assingments off the default any much good at obscuring the service.
> >
> > We are lucky in that most the coded sploits and POCs tend to be cheap in
> > that they tend to look for specifics in a very narrowly focused tunnel.
> > The potentials for something being crafted that is much more insidiously
> > inventive in determing attack vectors that might be non-norm are there.
> > And beaucse they remain at this time 'potential' should not be a reason or
> > rationale to try and place minimally effective or incomplete controls in
> > the security layers one uses.  The IT community has been repeatedly bitten
> > by doing less then they know better to do due to the potential of
> > something not yet unleashed, say 1988 for example.
> >
>
> There needs to be some differentiation between worms and exploits here.
> In the case of a single attacker specifically targeting a machine, then
> yes, I agree that a non-standard port configuration is not going to
> help due to such "insidiously inventive" tools as nmap and its -sV.
> However a non-standard port does help in the general case when it comes
> to a worm.
>
> The reason that we have not seen a worm search for non-standard
> configurations is not so much a lack of ingenuity by the authors,
> but more of a realisation that the time spent on scanning each target
> is better spent looking for other potentially vulnerable hosts with a
> standard port configuration. That is to say, searching each potential
> host for non-standard ports is inefficient and would likely inhibit the
> spread of such a worm.
>
> I don't have any figures to support this claim, but its hard to imagine
> the percentage of non-standard port configurations for any service on
> the internet being high enough to be an attractive target for a worm. In
> the end, running a service on a non-standard port at this point in time
> is a useful part of a layered security approach, if only to inhibit
> worms.
>
>

It might depend upon how the algorithim is implimented, say, search for
easy to find vuln systems with stadard port open, till perhaps 10 or 100
or some given number are found and infected, then go back through the
non-vuln hosts and search those specifically for non-standard ports.
Insures spread of the worm and quick infection rate, and then allows it to
retarget 'hidden' systems.  Seems to me this would merely be a change to
infection code similiar to those wrms that had in them coded a date and
time to attack a site.

I agree that the milage one might get out of non-standard porting of a
service might give them some advantages in some attack situations, but, I
would not bet my security posture upon such.  Ports are not the problem
for sure, without anything running behind a port, it's innate, it;s the
protocols that are allowed to run on a port or specific set of ports that
are the problem.  Something that I need to explain to our security folks
each time they run a scan for ports on our unix systems and note they
appear to be running some windows based application/port combo.


Seriously, why do folks think sshd should be open for the world to pound
upon, no matter which port it's assinged to run on?  It provides an
encrypted channel into the network.  And channel in, especially encrypted
channels, should be guarded and allow only those that require access to
get access.

Thanks,


Ron DuFresne
-- 
"Sometimes you get the blues because your baby leaves you. Sometimes you get'em
'cause she comes back." --B.B. King
        ***testing, only testing, and damn good at it too!***

OK, so you're a Ph.D.  Just don't touch anything.



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ