Ok, ok, no offence intended.
Can we mitigate it somewhat like what Roger Klorese suggested,
eg: restrict the info EHLO reveals or don't reveal actual hostname :
smtp_helo_name ($myhostname)
Use a fictitious hostname to send in the SMTP EHLO or HELO
command (& how do I do this?)
& from the url http://www.postfix.org/lmtp.8.html, can I insert something
like the following in main.cf :
smtp_never_send_ehlo (no)
Never send EHLO at the start of an SMTP session.
& from the url http://www.postfix.org/postconf.5.html
$helo_name
The hostname given in HELO or EHLO command or empty string
(& where & what's the syntax to set the above suggestions?)
Roger
On Tue, May 3, 2011 at 11:56 PM, Roger B.A. Klorese <rog...@queernet.org> wrote:
>
> On May 3, 2011, at 8:49 AM, Reindl Harald wrote:
>
> Am 03.05.2011 17:34, schrieb Roger Goh:
>
> Hi,
>
> During a VA scan, it's reported that my postfix server has
>
> a security vulnerability :
>
> EhloCheck: SMTP daemon supports EHLO
>
> where exactly is the security hole?
>
> you should not trust the output of every tool blind without
> try to understand what the output means
>
> EHLO is a part of ESMTP
> ____________________
>
> http://en.wikipedia.org/wiki/ESMTP
> Some relatively common keywords (not all of them corresponding to commands)
> used today are:
>
> * 8BITMIME — 8 bit data transmission, RFC 6152
> * ATRN — Authenticated TURN for On-Demand Mail Relay, RFC 2645
> * SMTP-AUTH — Authenticated SMTP, RFC 4954
> * CHUNKING — Chunking, RFC 3030
> * DSN — Delivery status notification, RFC 3461 (See Variable envelope
> return path)
> * ETRN — Extended version of remote message queue starting command TURN,
> RFC 1985
> * HELP — Supply helpful information, RFC 821
> * PIPELINING — Command pipelining, RFC 2920
> * SIZE — Message size declaration, RFC 1870
> * STARTTLS — Transport layer security, RFC 3207 (2002)
> * UTF8SMTP — Allow UTF-8 encoding in mailbox names and header fields, RFC
> 5336
>
>
>
> Quoting http://www.iss.net/security_center/reference/vuln/smtp-ehlo.htm
> Note that:
> - the SMTP standard requires it
> - it's rated as low-risk
> - You can restrict the info it shows
> SMTP daemon supports EHLO (EhloCheck)
>
> Vuln ID:323
> Risk Level: LowEhloCheck
> Platforms:IBM AIX, WindRiver BSDOS, SGI IRIX, Linux Kernel, Sun Solaris, IETF
> SMTP, IBM OS2, Microsoft Windows 95, Data General DG/UX, Microsoft Windows
> NT: 4.0, Microsoft Windows 98, SCO SCO Unix, Microsoft Windows 98SE,
> Microsoft Windows 2000, Microsoft Windows Me, Compaq Tru64, Microsoft Windows
> XP, Apple Mac OS, Microsoft Windows 2003 Server, Microsoft Windows Vista
> Description:
>
> SMTP daemons that support Extended HELO (EHLO) can release information that
> could be useful to an attacker in performing an attack. Attackers have been
> known to use the EHLO command to determine configuration information on SMTP
> daemons.
>
> Remedy:
>
> SMTP as defined in RFC 2821 (see References) requires EHLO. Some SMTP
> implementations allow you to disable EHLO, but this capability is neither
> required nor consistent across products.
>
> If you are uncomfortable with the information that the Extended SMTP features
> can reveal, you may choose to disable EHLO on your mail server (if
> applicable), or switch to a mail server that allows EHLO to be disabled.
> Consult your mail server documentation or contact your vendor for information
> on whether it is possible to modify your mail server configuration to disable
> EHLO.
