Re: Server Vulnerability Scan

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: keith smith
Date:  
To: Main PLUG discussion list
Subject: Re: Server Vulnerability Scan
Thank you Lisa and Matt!

Lots of info, thanks!

------------------------
Keith Smith


--- On Tue, 1/5/10, Matt Graham <> wrote:

> From: Matt Graham <>
> Subject: Re: Server Vulnerability Scan
> To: "Main PLUG discussion list" <>
> Date: Tuesday, January 5, 2010, 9:54 AM
> From: keith smith <>
> > Part of what I am tasked with is keeping the cart PCI
> complaint.
>
> That's one of those typos that actually makes more sense
> than it
> would if speled correctly :-).
>
> > We hired a company who scans our server and reports
> back to us.
> > They report :
> > We were able to determine which versions of the SSH
> protocol the
> > remote SSH daemon supports. This gives potential
> attackers
> > additional information about the system they are
> attacking.
>
> sshd tells the client "I support protocol
> 2" or "I support protocol 1" or "I support both
> protocols".  It's
> not possible AFAICT to not do that and still be able to run
> ssh
> with a standard client.  The thing that'd probably
> work is to run
> knockd (or something that implements Single Packet
> Authentication,
> or something like that).  Have an iptables rule that
> REJECTs all
> traffic on the port you're running sshd on when SYN is
> set.  Then
> knockd or whatever inserts an iptables rule that ACCEPTs
> traffic
> with SYN set from the IP that submits a successful knock
> request
> (or valid SPA request) for ~30 seconds.
>
> It is apparently possible to send so many packets so
> quickly that
> knockd can be overwhelmed for short knock sequences, so
> either
> make the sequence long or think about SPA.
>
> Most PCI scanning companies do a minimum amount of
> effort.  I was
> annoyed when they said, "Version X.Y has a vulnerability in
> the
> IMAP functions."  I compiled that package and made it
> so all the
> IMAP functions were commented out.  Then I installed
> that on a
> test box, and had them scan that test box.  Yep, we
> still got
> dinged for a vulnerability in functions that were not even
> there.
> It may help to think of PCI compliance as a bureaucratic
> problem,
> not a technical one, because that's how it seems to play
> out.
>
> > I've looked in the sshd_config and find nothing that
> would alert
> > me to how I can turn off reporting its config or its
> existence.
>
> I don't think you can do that and still have sshd work
> properly.
> But try an alternative approach, like the one above or the
> one
> that Lisa mentioned late yesterday.
>
> --
> Matt G / Dances With Crows
> The Crow202 Blog:  http://crow202.org/wordpress/
> There is no Darkness in Eternity/But only Light too dim for
> us to see
>
>
> ---------------------------------------------------
> PLUG-discuss mailing list -
> To subscribe, unsubscribe, or to change your mail
> settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>




---------------------------------------------------
PLUG-discuss mailing list -
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss