The only warning was that id does not support TLS:
SMTP TLS Warning - Does not support TLS. More Info
SMTP Reverse Banner Check OK - aa.bb.cc.ddd resolves to aa.bb.cc.ddd.in-addr.arpa, my.website.com
SMTP Reverse DNS Mismatch OK - Reverse DNS matches SMTP Banner
SMTP Connection Time 0.889 seconds - Good on Connection time
SMTP Open Relay OK - Not an open relay.
SMTP Transaction Time 3.058 seconds - Good on Transaction Time
Session Transcript:
Connecting to aa.bb.cc.ddd
However, since couple days I’ve been changing lot’s of configurations, so probably the issue is not there already, so I need to have Trustwave’s robot to scan the server once again. Thanks and I’ll report again if the issue persists after the second scan.
Today Truswave replied back denying our request to make an exclusion to this policy. Their findings are below:
We have denied this dispute based upon manual investigation of this finding.
Manual Investigation:
telnet xx.xx.xx.xx 25
Trying xx.xx.xx.xx…
Connected to my.website.tld (xx.xx.xx.xx).
Escape character is ‘^]’.
h220 my.website.tld ESMTP Postfix helho scan_css_util
502 5.5.2 Error: command not recognized
helo secure.server.com
250 my.website.tld
MAIL FROM:(>
250 2.1.0 Ok
rcpt to: root@[xx.xx.xx.xx]
250 2.1.5 Ok
data
354 End data with .
From: “Bob” bob@example.org
To: “Alice” alice@example.com
Date: Today
Hello Alice.
This is a test message.
Bob
.
250 2.0.0 Ok: queued as 62B381A39F
quit
221 2.0.0 Bye
Connection closed by foreign host.
Any issues detected on a system that is in scope for PCI DSS compliance would need to have all PCI non-compliant issues remediated (which is any system involved in the storage, processing, and/or transmission of credit card holder data and any system directly connected to a network involved in such processes which does not have proper network segmentation in place).
Please review the scan report and follow the suggestions found underneath the “Remediation” column and then perform another scan when the vulnerability has been remediated to clear the finding from your next scan report.
If the vulnerability continues to be detected after this point and/or if you have already performed this then please feel free to re-dispute this vulnerability and explain what was performed to address the finding.
Could anyone please help me to sort this out? Thanks!
Hmm, I’m confused as to why they’re raising an issue – what’s described in the test they performed doesn’t appear to be any sort of security issue.
It’s simply sending an email to the root user on that server, with a fictional “from” and “to” address.
The issue “CVE-1999-0512” describes a security issue where a server is an open relay, meaning it accepts email from spammers, and sends them to any server on the Internet.
I’m not seeing anything that suggests that your server is an open relay – and the test they performed isn’t checking to see if your server is an open relay, it’s just delivering an email locally.
Also, since the mxmailbox site didn’t discover anything either – I suspect what they’re seeing is some sort of false positive.
We haven’t changed anything on this server lately and it would pass the test before just fine, but the last time Trustwave found this vulnerability. The “postconf -n” command gives:
We have denied this dispute based on the information provided. By confirming that “root@[LOCALIP]” and/or “postmaster@[LOCALIP]” are valid addresses is saying that any Spammers delivering email by using MAIL FROM:(> (hiding source address) have the ability to eat up bandwidth with an overabundance of unsolicited messages. As such, we have denied this dispute.
Any issues detected on a system that is in scope for PCI DSS compliance would need to have all PCI non-compliant issues remediated (which is any system involved in the storage, processing, and/or transmission of credit card holder data and any system directly connected to a network involved in such processes which does not have proper network segmentation in place).
Please review the scan report and follow the suggestions found underneath the “Remediation Action” column and then perform another scan when the vulnerability has been remediated to clear the finding from your next scan report. If the vulnerability continues to be detected after this point and/or if you have already performed this then please feel free to re-dispute this vulnerability and explain what was performed to address the finding.
Also, please be advised that we cannot grant current disputes using information contained in previous or other disputes (or information contained within emails or phone calls as well); all applicable information must be included in the most current dispute so please include all pertinent information within your disputes.
I am now lost how should I address this issue…
By the way, cite doesn’t work in comments. I generally find markup on virtualmin.com’s forums terrible. Why don’t you install some kind of WYSWIG here?
Unfortunately, I don’t feel what they’re saying makes sense, or has anything to do with the security issue they’re mentioning.
They’re suggesting that simply knowing a local email address is a security issue because someone can send lots of email to it.
That doesn’t make sense to me
The security issue they’re claiming (CVE-1999-0512) is related to being an open relay – but that has nothing to do with what they’re describing. They have not shown that you are an open relay.
There are a number of email addresses that every domain is supposed to have – such as “hostmaster@domain.tld”.
Since every domain should have these email addresses – of course someone could send email to it… that’s not a security issue, that’s where bad emails should be stopped with anti-spam software and RBL’s.
Off the top of my head, I’m not sure how one might prevent what they’re describing without causing problems with legitimate emails to the root user. Are they providing an example of how they would configure Postfix to prevent the issue they have?
I also have no idea why it should be a security issue to allow the address root@[ip-address]. My system accepts that address too. Just as root@host.domain.tld. Don’t those addresses exist on about every Linux system?