Re: [Full-Disclosure] OpenSSH is a good choice?

From: Ron DuFresne (dufresne_at_winternet.com)
Date: 12/24/04

  • Next message: Aviv Raff: "RE: [Full-Disclosure] YEY AGAIN Automatic remote compromise of InternetExplorer Service Pack 2 XP SP2"
    Date: Fri, 24 Dec 2004 16:00:45 -0600 (CST)
    To: Ben Hawkes <ben.hawkes@paradise.net.nz>
    
    

    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.
    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.netsys.com/full-disclosure-charter.html
    

  • Next message: Aviv Raff: "RE: [Full-Disclosure] YEY AGAIN Automatic remote compromise of InternetExplorer Service Pack 2 XP SP2"

    Relevant Pages

    • Re: SSH Brute Force attempts
      ... past I've used various tips and tricks with linux boxes but many of them ... not protect you if you have weak passwords. ... different, non-standard port (e.g. 222 or whatever, but it ... anywhere else if necessary by using the non-standard port. ...
      (freebsd-hackers)
    • RE: [fw-wiz] RE: In defense of non standard ports
      ... A good firewall should have the capability of allowing its firewall rules to ... So, even though it is a port other than 80/443, there should be the ... >From internal:any to specifichost:1234 allow HTTPS ... It is not the non-standard port that is the problem, ...
      (Firewall-Wizards)
    • Re: throttle ssh logins (OpenSSH sshd)
      ... different port number. ... I stick them into /etc/hosts with deny. ... machines. ... assuming that using a non-standard port is not an option. ...
      (comp.security.ssh)
    • Re: Thousands of ssh probes
      ... that case he will scan large ip-ranges for hosts listening on port 22. ... The attacker wants to gain control of a particular server. ... Running ssh on a non-standard port is likely to ...
      (freebsd-questions)
    • Re: Video Conferencing through ISA 2004
      ... if you want a filter to apply to a non-standard port you should ... create such a protocol in ISA). ...
      (microsoft.public.isa)