How to disabale VRFY and/or EXPN requests

adnanbutt0550 · January 20, 2020, 10:54am

Hello,

Today, I was doing some security checks on Nethserver using OpenVAS via Ubuntu 18.04.
OpenVas find the following vulnerability and suggest me a solution to disable the VRFY and EXPN request on Mailserver. But I don’t know how I can disable these kinds of requests?

pike · January 20, 2020, 12:37pm

Well… root is the only user that cannot… not be present on every unix/linux system. Even BSD.
So (d’oh) it’s quite common the answer root to VRFY. Question is: does the VRFY whatever will give any answer? IMVHO the query is quite pointless and useless…

Anyway: postfix has a directive into main.cf for disable it
http://www.postfix.org/postconf.5.html#disable_vrfy_command
Question is: which is the correct template to implement that?

royceb · January 20, 2020, 2:17pm

Solution:
Disable VRFY and/or EXPN on your Mailserver.

For postfix add ‘disable_vrfy_command=yes’ in ‘main.cf’.

For Sendmail add the option ‘O PrivacyOptions=goaway’.

Does this help?

danb35 · January 20, 2020, 2:49pm

Vulnerability Insight:
VRFY and EXPN ask the server for information about an address. They are
inherently unusable through firewalls, gateways, mail exchangers for part-time hosts, etc.

That, um, isn’t very insightful. I suppose (though they don’t bother to say it) the concern is that it gives a bad actor a relatively easy way to check whether an account exists on your server, but calling that a “vulnerability” sounds like a bit of a stretch.

danb35 · January 20, 2020, 2:53pm

I expect the reason root is queried is because it’s guaranteed to be there on pretty much any Unix-y system, but the real issue (though once again, I’m only guessing, because they don’t bother to explain why they believe this to be a problem) is that it responds to VRFY at all. Here’s what my server does:

250 DSN
VRFY dan
252 2.0.0 dan
VRFY nonexistent
550 5.1.1 <nonexistent>: Recipient address rejected: User unknown in local recipient table
DONE

filippo_carletti · January 20, 2020, 3:17pm

@adnanbutt0550 is probably running openvas from a trusted network. False positives are almost guaranteed.

adnanbutt0550 · January 20, 2020, 3:54pm

Hello

@filippo_carletti yes, Openvas is running from the trusted network.

danb35 · January 20, 2020, 5:34pm

I don’t see that it would make a difference–the SMTP server is accessible on red and green. Is it configured to respond differently to the VRFY command between the two? I could probably test this on mine, but it’ll take a bit before I could get to it.

I do agree it’s a false positive, but that’s because I don’t believe the so-called “vulnerability” is actually a vuln–but since they don’t bother to explain why they flag it, it’s kind of hard to say.

danb35 · January 20, 2020, 6:59pm

Well, shows what I know–here’s the output if I connect from a non-trusted network:

---
250 DSN
VRFY root
554 5.7.1 <mobile-166-177-184-131.mycingular.net[166.177.184.131]>: Client host rejected: Access denied
VRFY dan
554 5.7.1 <mobile-166-177-184-131.mycingular.net[166.177.184.131]>: Client host rejected: Access denied
VRFY nonexistent
554 5.7.1 <mobile-166-177-184-131.mycingular.net[166.177.184.131]>: Client host rejected: Access denied
DONE