[Chugalug] PCI Compliance Question for SSH

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

[Chugalug] PCI Compliance Question for SSH

David White-2
I do a lot of web hosting, but haven't really had to deal much with PCI compliance.
I have a client who wants me to launch a VPS for them, and get them off of a shared environment, so that we can better secure the system and address some PCI compliance concerns.

It seems that one of the bigger complaints that their PCI compliance scans come up with are related to OpenSSH and SCP.

I think I've decided to install OpenVPN as a server on a Jump Box, and connect the new VPS to that OpenVPN server, and then configure OpenSSH, etc... to only listen on the VPN interface.

Am I crazy and setting myself up for failure? 
Or can any of you think of a better solution?

--
David White

_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug
Reply | Threaded
Open this post in threaded view
|

Re: [Chugalug] PCI Compliance Question for SSH

Dave Brockman
On 11/23/2019 8:52 AM, David White wrote:
> I do a lot of web hosting, but haven't really had to deal much with PCI
> compliance.
> I have a client who wants me to launch a VPS for them, and get them off
> of a shared environment, so that we can better secure the system and
> address some PCI compliance concerns.
>
> It seems that one of the bigger complaints that their PCI compliance
> scans come up with are related to OpenSSH and SCP.

Do the Scans complain about ciphers or just the fact that SSH is present
and accepting connections?


> I think I've decided to install OpenVPN as a server on a Jump Box, and
> connect the new VPS to that OpenVPN server, and then configure OpenSSH,
> etc... to only listen on the VPN interface.
>
> Am I crazy and setting myself up for failure? 
> Or can any of you think of a better solution?

Assuming you control 1.2.3.0/24 and 11.12.13.14:

iptables -A INPUT -p tcp -s 1.2.3.0/24 --dport 22 -m conntrack --ctstate
NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -s 11.12.13.14 --dport 22 -m conntrack
--ctstate NEW,ESTABLISHED -j ACCEPT

Then the usual, deny root login, force keys, no passwords, etc.  If
you're going to limit to the jump box anyway, there is no need for the
VPN (and another point of failure), IMO.

Cheers,

-Dave




_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Chugalug] PCI Compliance Question for SSH

David White-2
Thanks, Dave.
The scans are complaining that SSH is accepting connections at all.

CentOS 8 comes with OpenSSH 7.8 by default, which addresses a majority of the issues, but not all of them.
If I can find a software stream repo that will provide OpenSSH >=8, then I think we'd be fine.
No way I'm going to start compiling my own packages of openssh.

I do of course already have SSH configured to deny root and force keys.
I've also tightened up the ciphers and such.

I didn't think about using iptables rules to do this, but that makes a lot of sense.
I was envisioning needing to setup a completely separate interface on a private IP address (hence, the VPN), but you're right -- I can do this in iptables, and block SSH connections from untrusted sources before they even hit the sshd daemon. 

On Sat, Nov 23, 2019 at 11:03 AM Dave Brockman <[hidden email]> wrote:
On 11/23/2019 8:52 AM, David White wrote:
> I do a lot of web hosting, but haven't really had to deal much with PCI
> compliance.
> I have a client who wants me to launch a VPS for them, and get them off
> of a shared environment, so that we can better secure the system and
> address some PCI compliance concerns.
>
> It seems that one of the bigger complaints that their PCI compliance
> scans come up with are related to OpenSSH and SCP.

Do the Scans complain about ciphers or just the fact that SSH is present
and accepting connections?


> I think I've decided to install OpenVPN as a server on a Jump Box, and
> connect the new VPS to that OpenVPN server, and then configure OpenSSH,
> etc... to only listen on the VPN interface.
>
> Am I crazy and setting myself up for failure? 
> Or can any of you think of a better solution?

Assuming you control 1.2.3.0/24 and 11.12.13.14:

iptables -A INPUT -p tcp -s 1.2.3.0/24 --dport 22 -m conntrack --ctstate
NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -s 11.12.13.14 --dport 22 -m conntrack
--ctstate NEW,ESTABLISHED -j ACCEPT

Then the usual, deny root login, force keys, no passwords, etc.  If
you're going to limit to the jump box anyway, there is no need for the
VPN (and another point of failure), IMO.

Cheers,

-Dave



_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug


--
David White

_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug
Reply | Threaded
Open this post in threaded view
|

Re: [Chugalug] PCI Compliance Question for SSH

William Roush

I’ve had 3rd party scanners yell about stupid stuff for no good reason.

 

Does it actually call out a violation of a specific part of PCI-DSS? Which SAQ are you trying to aim for (since you’re not relying on a QSA I’m assuming it’s a SAQ)?

 

It’s been awhile since I did the full SAQ D + Merchant QSA compliance but I don’t remember anything saying that SSH could not be open to the internet. A bunch of rules about how it’s done (strong passwords, strong ciphers, etc.), but not that it can’t be done.

 

William Roush | https://www.roushtech.net/

Office: 423.933.2114 | Cell: 423.463.0592 | Email: [hidden email]

 

 

 

From: Chugalug <[hidden email]> On Behalf Of David White
Sent: Saturday, November 23, 2019 1:01 PM
To: Cha. Unix Gnu Android Linux User Group <[hidden email]>
Subject: Re: [Chugalug] PCI Compliance Question for SSH

 

Thanks, Dave.

The scans are complaining that SSH is accepting connections at all.

 

CentOS 8 comes with OpenSSH 7.8 by default, which addresses a majority of the issues, but not all of them.

If I can find a software stream repo that will provide OpenSSH >=8, then I think we'd be fine.

No way I'm going to start compiling my own packages of openssh.

 

I do of course already have SSH configured to deny root and force keys.

I've also tightened up the ciphers and such.

 

I didn't think about using iptables rules to do this, but that makes a lot of sense.

I was envisioning needing to setup a completely separate interface on a private IP address (hence, the VPN), but you're right -- I can do this in iptables, and block SSH connections from untrusted sources before they even hit the sshd daemon. 

 

On Sat, Nov 23, 2019 at 11:03 AM Dave Brockman <[hidden email]> wrote:

On 11/23/2019 8:52 AM, David White wrote:
> I do a lot of web hosting, but haven't really had to deal much with PCI
> compliance.
> I have a client who wants me to launch a VPS for them, and get them off
> of a shared environment, so that we can better secure the system and
> address some PCI compliance concerns.
>
> It seems that one of the bigger complaints that their PCI compliance
> scans come up with are related to OpenSSH and SCP.

Do the Scans complain about ciphers or just the fact that SSH is present
and accepting connections?


> I think I've decided to install OpenVPN as a server on a Jump Box, and
> connect the new VPS to that OpenVPN server, and then configure OpenSSH,
> etc... to only listen on the VPN interface.
>
> Am I crazy and setting myself up for failure? 
> Or can any of you think of a better solution?

Assuming you control 1.2.3.0/24 and 11.12.13.14:

iptables -A INPUT -p tcp -s 1.2.3.0/24 --dport 22 -m conntrack --ctstate
NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -s 11.12.13.14 --dport 22 -m conntrack
--ctstate NEW,ESTABLISHED -j ACCEPT

Then the usual, deny root login, force keys, no passwords, etc.  If
you're going to limit to the jump box anyway, there is no need for the
VPN (and another point of failure), IMO.

Cheers,

-Dave



_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug


 

--

David White


_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug
Reply | Threaded
Open this post in threaded view
|

Re: [Chugalug] PCI Compliance Question for SSH

Dave Brockman
On 11/24/2019 9:58 PM, William Roush wrote:
> It’s been awhile since I did the full SAQ D + Merchant QSA compliance
> but I don’t remember /anything/ saying that SSH could not be open to the
> internet. A bunch of rules about /how/ it’s done (strong passwords,
> strong ciphers, etc.), but not that it can’t be done.

Trustwave, in particular, likes to flag SSH open to public.  There are
two ways around this.  1) limit SSH availability so the scanning doesn't
see it, or 2) (Say it with me) "We accept the risk of running SSH".

Cheers,

-Dave


_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Chugalug] PCI Compliance Question for SSH

William Roush
Yeah generic security scans can catch all different kinds of things that aren't actually hard PCI-DSS failures.


William Roush | https://www.roushtech.net/
Office: 423.933.2114 | Cell: 423.463.0592 | Email: [hidden email]



-----Original Message-----
From: Chugalug <[hidden email]> On Behalf Of Dave Brockman
Sent: Monday, November 25, 2019 12:12 PM
To: [hidden email]
Subject: Re: [Chugalug] PCI Compliance Question for SSH

On 11/24/2019 9:58 PM, William Roush wrote:
> It’s been awhile since I did the full SAQ D + Merchant QSA compliance
> but I don’t remember /anything/ saying that SSH could not be open to
> the internet. A bunch of rules about /how/ it’s done (strong
> passwords, strong ciphers, etc.), but not that it can’t be done.

Trustwave, in particular, likes to flag SSH open to public.  There are two ways around this.  1) limit SSH availability so the scanning doesn't see it, or 2) (Say it with me) "We accept the risk of running SSH".

Cheers,

-Dave

_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug
Reply | Threaded
Open this post in threaded view
|

Re: [Chugalug] PCI Compliance Question for SSH

David White-2
Trustwave, in particular, likes to flag SSH open to public.  There are
two ways around this.  1) limit SSH availability so the scanning doesn't
see it, or 2) (Say it with me) "We accept the risk of running SSH".

They are indeed the ones doing the compliance scan. 
Try explaining the concept of "accepting the risk" and "mitigating controls" to a small nonprofit organization that doesn't understand concepts like that -- when they have a big fat "compliance report" in front of them showing that OpenSSH (and SCP) has about 10 different vulnerabilities. 

I discussed at length with this particular client, and gave them the option to go with a managed VPS, and that's what they decided to do.
I encouraged them several times to investigate whether or not they were actually required to meet the compliance standards, and told them several times that our shared hosting infrastructure was "secure". 
While they believed me and trust me, they preferred to go with the VPS so in the end, that's what we went with.


On Mon, Nov 25, 2019 at 6:55 PM William Roush <[hidden email]> wrote:
Yeah generic security scans can catch all different kinds of things that aren't actually hard PCI-DSS failures.


William Roush | https://www.roushtech.net/
Office: 423.933.2114 | Cell: 423.463.0592 | Email: [hidden email]



-----Original Message-----
From: Chugalug <[hidden email]> On Behalf Of Dave Brockman
Sent: Monday, November 25, 2019 12:12 PM
To: [hidden email]
Subject: Re: [Chugalug] PCI Compliance Question for SSH

On 11/24/2019 9:58 PM, William Roush wrote:
> It’s been awhile since I did the full SAQ D + Merchant QSA compliance
> but I don’t remember /anything/ saying that SSH could not be open to
> the internet. A bunch of rules about /how/ it’s done (strong
> passwords, strong ciphers, etc.), but not that it can’t be done.

Trustwave, in particular, likes to flag SSH open to public.  There are two ways around this.  1) limit SSH availability so the scanning doesn't see it, or 2) (Say it with me) "We accept the risk of running SSH".

Cheers,

-Dave

_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug


--
David White

_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug
Reply | Threaded
Open this post in threaded view
|

Re: [Chugalug] PCI Compliance Question for SSH

William Roush
  • when they have a big fat "compliance report" in front of them showing that OpenSSH (and SCP) has about 10 different vulnerabilities. 

 

Oh on that note, I’ve had a *very* bad history of having scanners determine software versions and flag a ton of exploits, even though those were fixed by the distribution’s repo maintainers via backporting patches to the version they’re locked to.

 

For the most part sending a bunch of false-positive reports showing “CVE-XXX was fixed in whatever-Ubuntu12 which is reported as v1.2.3” got us past all of that, but it was a massive amount of manual work looking up every CVE and cross-referencing patches applied to the repository and showing we had those patches applied. On top of 3rd party scans easily costing 5 figures this stuff gets so expensive so fast for no good reason.

 

It’s part of why I kind of grumble that the security industry is a racket, half the time I’ve gone over this with companies running these scanners they had no clue what we were talking about, sigh…

 

William Roush | https://www.roushtech.net/

Office: 423.933.2114 | Cell: 423.463.0592 | Email: [hidden email]

 

 

 

From: Chugalug <[hidden email]> On Behalf Of David White
Sent: Monday, November 25, 2019 7:11 PM
To: Cha. Unix Gnu Android Linux User Group <[hidden email]>
Subject: Re: [Chugalug] PCI Compliance Question for SSH

 

Trustwave, in particular, likes to flag SSH open to public.  There are
two ways around this.  1) limit SSH availability so the scanning doesn't
see it, or 2) (Say it with me) "We accept the risk of running SSH".

 

They are indeed the ones doing the compliance scan. 

Try explaining the concept of "accepting the risk" and "mitigating controls" to a small nonprofit organization that doesn't understand concepts like that -- when they have a big fat "compliance report" in front of them showing that OpenSSH (and SCP) has about 10 different vulnerabilities. 

 

I discussed at length with this particular client, and gave them the option to go with a managed VPS, and that's what they decided to do.

I encouraged them several times to investigate whether or not they were actually required to meet the compliance standards, and told them several times that our shared hosting infrastructure was "secure". 

While they believed me and trust me, they preferred to go with the VPS so in the end, that's what we went with.

 

 

On Mon, Nov 25, 2019 at 6:55 PM William Roush <[hidden email]> wrote:

Yeah generic security scans can catch all different kinds of things that aren't actually hard PCI-DSS failures.


William Roush | https://www.roushtech.net/
Office: 423.933.2114 | Cell: 423.463.0592 | Email: [hidden email]



-----Original Message-----
From: Chugalug <[hidden email]> On Behalf Of Dave Brockman
Sent: Monday, November 25, 2019 12:12 PM
To: [hidden email]
Subject: Re: [Chugalug] PCI Compliance Question for SSH

On 11/24/2019 9:58 PM, William Roush wrote:
> It’s been awhile since I did the full SAQ D + Merchant QSA compliance
> but I don’t remember /anything/ saying that SSH could not be open to
> the internet. A bunch of rules about /how/ it’s done (strong
> passwords, strong ciphers, etc.), but not that it can’t be done.

Trustwave, in particular, likes to flag SSH open to public.  There are two ways around this.  1) limit SSH availability so the scanning doesn't see it, or 2) (Say it with me) "We accept the risk of running SSH".

Cheers,

-Dave

_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug


 

--

David White


_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug
Reply | Threaded
Open this post in threaded view
|

Re: [Chugalug] PCI Compliance Question for SSH

David White-2
Yeah, unfortunately, some of the CVEs have indeed not been backported.
We successfully "disputed" a number of the issues that came up, and addressed a few more by tightening up the ciphers and what-not, but I confirmed that RedHat (and thus CentOS) were not going to address a few of the CVEs that popped up.

On Mon, Nov 25, 2019 at 7:39 PM William Roush <[hidden email]> wrote:
  • when they have a big fat "compliance report" in front of them showing that OpenSSH (and SCP) has about 10 different vulnerabilities. 

 

Oh on that note, I’ve had a *very* bad history of having scanners determine software versions and flag a ton of exploits, even though those were fixed by the distribution’s repo maintainers via backporting patches to the version they’re locked to.

 

For the most part sending a bunch of false-positive reports showing “CVE-XXX was fixed in whatever-Ubuntu12 which is reported as v1.2.3” got us past all of that, but it was a massive amount of manual work looking up every CVE and cross-referencing patches applied to the repository and showing we had those patches applied. On top of 3rd party scans easily costing 5 figures this stuff gets so expensive so fast for no good reason.

 

It’s part of why I kind of grumble that the security industry is a racket, half the time I’ve gone over this with companies running these scanners they had no clue what we were talking about, sigh…

 

William Roush | https://www.roushtech.net/

Office: 423.933.2114 | Cell: 423.463.0592 | Email: [hidden email]

 

 

 

From: Chugalug <[hidden email]> On Behalf Of David White
Sent: Monday, November 25, 2019 7:11 PM
To: Cha. Unix Gnu Android Linux User Group <[hidden email]>
Subject: Re: [Chugalug] PCI Compliance Question for SSH

 

Trustwave, in particular, likes to flag SSH open to public.  There are
two ways around this.  1) limit SSH availability so the scanning doesn't
see it, or 2) (Say it with me) "We accept the risk of running SSH".

 

They are indeed the ones doing the compliance scan. 

Try explaining the concept of "accepting the risk" and "mitigating controls" to a small nonprofit organization that doesn't understand concepts like that -- when they have a big fat "compliance report" in front of them showing that OpenSSH (and SCP) has about 10 different vulnerabilities. 

 

I discussed at length with this particular client, and gave them the option to go with a managed VPS, and that's what they decided to do.

I encouraged them several times to investigate whether or not they were actually required to meet the compliance standards, and told them several times that our shared hosting infrastructure was "secure". 

While they believed me and trust me, they preferred to go with the VPS so in the end, that's what we went with.

 

 

On Mon, Nov 25, 2019 at 6:55 PM William Roush <[hidden email]> wrote:

Yeah generic security scans can catch all different kinds of things that aren't actually hard PCI-DSS failures.


William Roush | https://www.roushtech.net/
Office: 423.933.2114 | Cell: 423.463.0592 | Email: [hidden email]



-----Original Message-----
From: Chugalug <[hidden email]> On Behalf Of Dave Brockman
Sent: Monday, November 25, 2019 12:12 PM
To: [hidden email]
Subject: Re: [Chugalug] PCI Compliance Question for SSH

On 11/24/2019 9:58 PM, William Roush wrote:
> It’s been awhile since I did the full SAQ D + Merchant QSA compliance
> but I don’t remember /anything/ saying that SSH could not be open to
> the internet. A bunch of rules about /how/ it’s done (strong
> passwords, strong ciphers, etc.), but not that it can’t be done.

Trustwave, in particular, likes to flag SSH open to public.  There are two ways around this.  1) limit SSH availability so the scanning doesn't see it, or 2) (Say it with me) "We accept the risk of running SSH".

Cheers,

-Dave

_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug


 

--

David White

_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug


--
David White

_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug
Reply | Threaded
Open this post in threaded view
|

Re: [Chugalug] PCI Compliance Question for SSH

Stephen Kraus
In reply to this post by David White-2
As long as you are using pub key only auth, ssh is fine. I preffer it behind a firewall.

Bonus if you setup Google MFA PAM for SSH

On Mon, Nov 25, 2019, 7:11 PM David White <[hidden email]> wrote:
Trustwave, in particular, likes to flag SSH open to public.  There are
two ways around this.  1) limit SSH availability so the scanning doesn't
see it, or 2) (Say it with me) "We accept the risk of running SSH".

They are indeed the ones doing the compliance scan. 
Try explaining the concept of "accepting the risk" and "mitigating controls" to a small nonprofit organization that doesn't understand concepts like that -- when they have a big fat "compliance report" in front of them showing that OpenSSH (and SCP) has about 10 different vulnerabilities. 

I discussed at length with this particular client, and gave them the option to go with a managed VPS, and that's what they decided to do.
I encouraged them several times to investigate whether or not they were actually required to meet the compliance standards, and told them several times that our shared hosting infrastructure was "secure". 
While they believed me and trust me, they preferred to go with the VPS so in the end, that's what we went with.


On Mon, Nov 25, 2019 at 6:55 PM William Roush <[hidden email]> wrote:
Yeah generic security scans can catch all different kinds of things that aren't actually hard PCI-DSS failures.


William Roush | https://www.roushtech.net/
Office: 423.933.2114 | Cell: 423.463.0592 | Email: [hidden email]



-----Original Message-----
From: Chugalug <[hidden email]> On Behalf Of Dave Brockman
Sent: Monday, November 25, 2019 12:12 PM
To: [hidden email]
Subject: Re: [Chugalug] PCI Compliance Question for SSH

On 11/24/2019 9:58 PM, William Roush wrote:
> It’s been awhile since I did the full SAQ D + Merchant QSA compliance
> but I don’t remember /anything/ saying that SSH could not be open to
> the internet. A bunch of rules about /how/ it’s done (strong
> passwords, strong ciphers, etc.), but not that it can’t be done.

Trustwave, in particular, likes to flag SSH open to public.  There are two ways around this.  1) limit SSH availability so the scanning doesn't see it, or 2) (Say it with me) "We accept the risk of running SSH".

Cheers,

-Dave

_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug


--
David White
_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug

_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug
Reply | Threaded
Open this post in threaded view
|

Re: [Chugalug] PCI Compliance Question for SSH

Michael Harrison
In reply to this post by David White-2

Last time I passed PCI, (6 months ago) I turned off SSH. That server reverse tunnelled during the scans. Current environment uses OpenVPN.. and in an emergency, serial or KVM console access. 

BTW: The new Raritan KVM's are frigging awesome and don't require Java or Flash! (and not cheap).




On Mon, Nov 25, 2019 at 7:47 PM David White <[hidden email]> wrote:
Yeah, unfortunately, some of the CVEs have indeed not been backported.
We successfully "disputed" a number of the issues that came up, and addressed a few more by tightening up the ciphers and what-not, but I confirmed that RedHat (and thus CentOS) were not going to address a few of the CVEs that popped up.

On Mon, Nov 25, 2019 at 7:39 PM William Roush <[hidden email]> wrote:
  • when they have a big fat "compliance report" in front of them showing that OpenSSH (and SCP) has about 10 different vulnerabilities. 

 

Oh on that note, I’ve had a *very* bad history of having scanners determine software versions and flag a ton of exploits, even though those were fixed by the distribution’s repo maintainers via backporting patches to the version they’re locked to.

 

For the most part sending a bunch of false-positive reports showing “CVE-XXX was fixed in whatever-Ubuntu12 which is reported as v1.2.3” got us past all of that, but it was a massive amount of manual work looking up every CVE and cross-referencing patches applied to the repository and showing we had those patches applied. On top of 3rd party scans easily costing 5 figures this stuff gets so expensive so fast for no good reason.

 

It’s part of why I kind of grumble that the security industry is a racket, half the time I’ve gone over this with companies running these scanners they had no clue what we were talking about, sigh…

 

William Roush | https://www.roushtech.net/

Office: 423.933.2114 | Cell: 423.463.0592 | Email: [hidden email]

 

 

 

From: Chugalug <[hidden email]> On Behalf Of David White
Sent: Monday, November 25, 2019 7:11 PM
To: Cha. Unix Gnu Android Linux User Group <[hidden email]>
Subject: Re: [Chugalug] PCI Compliance Question for SSH

 

Trustwave, in particular, likes to flag SSH open to public.  There are
two ways around this.  1) limit SSH availability so the scanning doesn't
see it, or 2) (Say it with me) "We accept the risk of running SSH".

 

They are indeed the ones doing the compliance scan. 

Try explaining the concept of "accepting the risk" and "mitigating controls" to a small nonprofit organization that doesn't understand concepts like that -- when they have a big fat "compliance report" in front of them showing that OpenSSH (and SCP) has about 10 different vulnerabilities. 

 

I discussed at length with this particular client, and gave them the option to go with a managed VPS, and that's what they decided to do.

I encouraged them several times to investigate whether or not they were actually required to meet the compliance standards, and told them several times that our shared hosting infrastructure was "secure". 

While they believed me and trust me, they preferred to go with the VPS so in the end, that's what we went with.

 

 

On Mon, Nov 25, 2019 at 6:55 PM William Roush <[hidden email]> wrote:

Yeah generic security scans can catch all different kinds of things that aren't actually hard PCI-DSS failures.


William Roush | https://www.roushtech.net/
Office: 423.933.2114 | Cell: 423.463.0592 | Email: [hidden email]



-----Original Message-----
From: Chugalug <[hidden email]> On Behalf Of Dave Brockman
Sent: Monday, November 25, 2019 12:12 PM
To: [hidden email]
Subject: Re: [Chugalug] PCI Compliance Question for SSH

On 11/24/2019 9:58 PM, William Roush wrote:
> It’s been awhile since I did the full SAQ D + Merchant QSA compliance
> but I don’t remember /anything/ saying that SSH could not be open to
> the internet. A bunch of rules about /how/ it’s done (strong
> passwords, strong ciphers, etc.), but not that it can’t be done.

Trustwave, in particular, likes to flag SSH open to public.  There are two ways around this.  1) limit SSH availability so the scanning doesn't see it, or 2) (Say it with me) "We accept the risk of running SSH".

Cheers,

-Dave

_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug


 

--

David White

_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug


--
David White
_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug

_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug
Reply | Threaded
Open this post in threaded view
|

Re: [Chugalug] PCI Compliance Question for SSH

David White-2
As long as you are using pub key only auth, ssh is fine.

As long as you keep your servers patched, etc..., I wholeheartedly agree.
That said, standards are standards, and when you need to comply with something, sometimes "common sense" isn't good enough.

We all (or at least most of us) know that following a standard doesn't necessarily make you secure, but we also know that sometimes you don't have a choice, and you have to meet standards.
That's where I and my clients have found ourselves right now.

It wasn't possible for me to turn off SSH or put it behind a firewall or anything on the existing server, because that's a shared server running cPanel.
Hence, why I put them onto their own fully managed VPS.

I've seen results from at least 2-3 scans in the last year, and I'm confident that we'll pass the next scan or two.
If anything comes up in the next scan, I'll at least be able to address those results much more easily now that they are on their own VPS. 

On Mon, Nov 25, 2019 at 9:24 PM Michael Harrison <[hidden email]> wrote:

Last time I passed PCI, (6 months ago) I turned off SSH. That server reverse tunnelled during the scans. Current environment uses OpenVPN.. and in an emergency, serial or KVM console access. 

BTW: The new Raritan KVM's are frigging awesome and don't require Java or Flash! (and not cheap).




On Mon, Nov 25, 2019 at 7:47 PM David White <[hidden email]> wrote:
Yeah, unfortunately, some of the CVEs have indeed not been backported.
We successfully "disputed" a number of the issues that came up, and addressed a few more by tightening up the ciphers and what-not, but I confirmed that RedHat (and thus CentOS) were not going to address a few of the CVEs that popped up.

On Mon, Nov 25, 2019 at 7:39 PM William Roush <[hidden email]> wrote:
  • when they have a big fat "compliance report" in front of them showing that OpenSSH (and SCP) has about 10 different vulnerabilities. 

 

Oh on that note, I’ve had a *very* bad history of having scanners determine software versions and flag a ton of exploits, even though those were fixed by the distribution’s repo maintainers via backporting patches to the version they’re locked to.

 

For the most part sending a bunch of false-positive reports showing “CVE-XXX was fixed in whatever-Ubuntu12 which is reported as v1.2.3” got us past all of that, but it was a massive amount of manual work looking up every CVE and cross-referencing patches applied to the repository and showing we had those patches applied. On top of 3rd party scans easily costing 5 figures this stuff gets so expensive so fast for no good reason.

 

It’s part of why I kind of grumble that the security industry is a racket, half the time I’ve gone over this with companies running these scanners they had no clue what we were talking about, sigh…

 

William Roush | https://www.roushtech.net/

Office: 423.933.2114 | Cell: 423.463.0592 | Email: [hidden email]

 

 

 

From: Chugalug <[hidden email]> On Behalf Of David White
Sent: Monday, November 25, 2019 7:11 PM
To: Cha. Unix Gnu Android Linux User Group <[hidden email]>
Subject: Re: [Chugalug] PCI Compliance Question for SSH

 

Trustwave, in particular, likes to flag SSH open to public.  There are
two ways around this.  1) limit SSH availability so the scanning doesn't
see it, or 2) (Say it with me) "We accept the risk of running SSH".

 

They are indeed the ones doing the compliance scan. 

Try explaining the concept of "accepting the risk" and "mitigating controls" to a small nonprofit organization that doesn't understand concepts like that -- when they have a big fat "compliance report" in front of them showing that OpenSSH (and SCP) has about 10 different vulnerabilities. 

 

I discussed at length with this particular client, and gave them the option to go with a managed VPS, and that's what they decided to do.

I encouraged them several times to investigate whether or not they were actually required to meet the compliance standards, and told them several times that our shared hosting infrastructure was "secure". 

While they believed me and trust me, they preferred to go with the VPS so in the end, that's what we went with.

 

 

On Mon, Nov 25, 2019 at 6:55 PM William Roush <[hidden email]> wrote:

Yeah generic security scans can catch all different kinds of things that aren't actually hard PCI-DSS failures.


William Roush | https://www.roushtech.net/
Office: 423.933.2114 | Cell: 423.463.0592 | Email: [hidden email]



-----Original Message-----
From: Chugalug <[hidden email]> On Behalf Of Dave Brockman
Sent: Monday, November 25, 2019 12:12 PM
To: [hidden email]
Subject: Re: [Chugalug] PCI Compliance Question for SSH

On 11/24/2019 9:58 PM, William Roush wrote:
> It’s been awhile since I did the full SAQ D + Merchant QSA compliance
> but I don’t remember /anything/ saying that SSH could not be open to
> the internet. A bunch of rules about /how/ it’s done (strong
> passwords, strong ciphers, etc.), but not that it can’t be done.

Trustwave, in particular, likes to flag SSH open to public.  There are two ways around this.  1) limit SSH availability so the scanning doesn't see it, or 2) (Say it with me) "We accept the risk of running SSH".

Cheers,

-Dave

_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug


 

--

David White

_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug


--
David White
_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug
_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug


--
David White

_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug
Reply | Threaded
Open this post in threaded view
|

Re: [Chugalug] PCI Compliance Question for SSH

Dave Brockman
In reply to this post by David White-2
On 11/25/2019 7:11 PM, David White wrote:
>     /Trustwave, in particular, likes to flag SSH open to public.  There are
>     //two ways around this.  1) limit SSH availability so the scanning
>     doesn't
>     //see it, or 2) (Say it with me) "We accept the risk of running SSH"./
>
> /
> /
> They are indeed the ones doing the compliance scan. 

It smelled like one of theirs... :)

> Try explaining the concept of "accepting the risk" and "mitigating
> controls" to a small nonprofit organization that doesn't understand
> concepts like that -- when they have a big fat "compliance report" in
> front of them showing that OpenSSH (and SCP) has about 10 different
> vulnerabilities. 

I've been there, and done that.  It just depends upon the situation, and
whether the client is paying my time to validate or just to remediate.
Most people can understand the concept of "Yes, this service is running.
 The only user who can connect is X, and to connect, X has to have this
file, and the password to unlock it.  I also have automated means to
roll to a new key at any time in the case of a compromised or even lost
key".  Having 10 different vulns listed makes me think you're running an
older version of something though.

Cheers,

-Dave


_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Chugalug] PCI Compliance Question for SSH

Dave Brockman
In reply to this post by William Roush
On 11/25/2019 7:39 PM, William Roush wrote:
> Oh on that note, I’ve had a **very** bad history of having scanners
> determine software versions and flag a ton of exploits, even though
> those were fixed by the distribution’s repo maintainers via backporting
> patches to the version they’re locked to.

Yep>
> For the most part sending a bunch of false-positive reports showing
> “CVE-XXX was fixed in whatever-Ubuntu12 which is reported as v1.2.3” got
> us past all of that, but it was a massive amount of manual work looking
> up every CVE and cross-referencing patches applied to the repository and
> showing we had those patches applied. On top of 3^rd party scans easily
> costing 5 figures this stuff gets so expensive so fast for no good reason.

Yep, that's part about being paid to validate vs remediate.  One takes
time and manual labor, the other usually just requires a couple of
firewall tweaks.

>  
>
> It’s part of why I kind of grumble that the security industry is a
> racket, half the time I’ve gone over this with companies running these
> scanners they had no clue what we were talking about, /sigh…/

Actually engaging scanners for discussion is always an interesting
venture.  It's refreshing when you find one who actually knows WTF
you're talking about, but increasingly rare.

Cheers,

-Dave


_______________________________________________
Chugalug mailing list
[hidden email]
http://chugalug.org/cgi-bin/mailman/listinfo/chugalug

signature.asc (499 bytes) Download Attachment