Ipswitch Forums / Messaging / IMail Server / PCI Compliance Scan failure / Latest Posts

RE: PCI Compliance Scan failure

Martin9 — Wed, 09 Jul 2008 18:02:04 GMT

Hi John, Thanks for the info.

RE: PCI Compliance Scan failure

John T — Fri, 04 Jul 2008 21:06:56 GMT

Look through the archives. This is overzealuous auditing.

RE: PCI Compliance Scan failure

Martin9 — Thu, 03 Jul 2008 21:48:32 GMT

[quote][b]jgolden (9/10/2007)[/b][hr]When I run the VRFY command in a telnet window on port 25, it returns:
502 Command not implemented

When I run the EXPN command, it returns:
550 lists are confidential

[/quote]

I am telneting into my server using a dos prompt by typing telnet XX.XX.XX.XX 25

When I run the VRFY and EXPN commands at the telnet prompt I am recieving the same response as above

VRFY = 502 command not implemented

and

EXPN = 550 lists are confidential

The error below now has a base score of 5 which is causing me to fail my PCI DSS compliance.
It looks like it is failing because EXPN is returning "550 lists are confidential" not "550 Access Denied"! Any thoughts on how I can get around this issue?

Thank you,
Martin

Security warning found on port/service "smtp (25/tcp)"

Plugin

Category

Priority Ranking

Synopsis : It is possible to enumerate the names of valid users on the remote host. Description : The remote SMTP server answers to the EXPN and/or VRFY commands. The EXPN command can be used to find the delivery address of mail aliases, or even the full name of the recipients, and the VRFY command may be used to check the validity of an account. Your mailer should not allow remote users to use any of these commands, because it gives them too much information.

Solution : If you are using Sendmail, add the option : O PrivacyOptions=goaway in /etc/sendmail.cf.

Risk factor : Medium / CVSS Base Score : 5.0 (CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:N) Plugin output : EXPN root produces the following output : 550 lists are confidential

CVE : CVE-1999-0531, Other, references, :, OSVDB:12551

RE: PCI Compliance Scan failure

jgolden — Wed, 19 Sep 2007 09:34:10 GMT

I forgot to come back here and follow up on this issue.
I sent a message to Ipswitch support about this and they basically came back with the same thing you said. That the 550 and 502 codes are RFC compliant. I forwarded their take on the situation to the PCI scanning company and they came back with, "After doing some research, the following is what our scan is showing and why it is failing..." and then they listed the same results I stated earlier. I replied back with "...Ok?...Why is this a failure if the RFC says this is what it should be saying?" And I linked to the same RFC source you did.
They finally lowered the score to a 3 which is considered a non-critical failure. I don't see why it's a failure at all but at least we are shown as being compliant now.
I hate to say it but this shouldn't be a problem after 6 months since we will be switching over to Exchange server. Then we will have a whole different set of problems. ;)

RE: PCI Compliance Scan failure

dheritage — Tue, 18 Sep 2007 18:09:00 GMT

Honstly, I would go back to your PCI auditor and ask why the text after the 550 is an issue. Once you receive a 550, that in itself means you cannot do it and the entire text portion is for the human reader, not the 'automation'.

I think you have a more than valid point about passing even though their 'automation' thinks otherwise. Some programmer wrote some sloppy code imho.

For more reference / ammunition in your defense... [url]http://www.ietf.org/rfc/rfc0821.txt[/url]

Specifically starting around page 48, as it defines permanent error codes (those starting with a 5).

RE: PCI Compliance Scan failure

jgolden — Mon, 10 Sep 2007 09:26:25 GMT

Yes, I stopped and restarted SMTP.
The other options are already set the way you suggest. These were the settings we have always had. Still failing the test for some reason.
When I run the VRFY command in a telnet window on port 25, it returns:
502 Command not implemented

When I run the EXPN command, it returns:
550 lists are confidential

So we don't either command implemented. I read online somewhere that a valid response EXPN should return:
550 Access Denied!

This is probably what the Ipswitch tech was talking about.
Thanks.
John Olden

RE: PCI Compliance Scan failure

John T — Mon, 10 Sep 2007 03:22:47 GMT

1) After making changes, did you restart both the SMTP and QueueManager services?

2) Do not check "Disable SMTP Auth" that has nothing to do with this.

3) On the SMTP service, under Security,
Uncheck "Allow Remote view of local groups"
Check "Disable SMTP VRFY command"

PCI Compliance Scan failure

jgolden — Sun, 09 Sep 2007 14:44:22 GMT

We are required to run our IP address through a 3rd party security audit to comply with our credit card processing provider. Our security audit has been coming back with the following failure:

Synopsis : It is possible to enumerate the names of valid users on the remote host. Description : The remote SMTP server answers to the EXPN and/or VRFY commands. The EXPN command can be used to find the delivery address of mail aliases, or even the full name of the recipients, and the VRFY command may be used to check the validity of an account. Your mailer should not allow remote users to use any of these commands, because it gives them too much information. Solution: If you are using Sendmail, add the option : O PrivacyOptions=goaway in /etc/sendmail.cf. Risk Factor: Medium / CVSS Base Score : 5.0 (CVSS2#AV:N/AC:L/Au:N/C: P/I:N/A:N) CVE : CVE-1999-0531 Other references : OSVDB:12551
(NOTE: I added a space to the part between parentheses to prevent a smiley)

Is there a setting I'm missing to fix this issue?
We currently have the "Disable SMTP "VRFY" Command" checked on our server. Checking "Disable SMTP AUTH" in our SMTP settings makes no difference and it breaks our e-mail system for remote users using POP to send e-mail.
I believe I brought this up to Ipswitch support before but the answer was that they just returned an error message rather than not answering. We've been failling this test for a while but the securty auditing company recently upgraded this from a 1 point to a 4 point failure which makes us non-compliant for the scan. It wasn't a major issue before now.

Thanks.
John