Koozali.org: home of the SME Server

Security audit on SME server

Upaboveit

Security audit on SME server
« on: June 07, 2003, 08:45:10 PM »
I've recently had a security audit done through this place: https://secure1.securityspace.com/sspace/index.html

During testing I received this mail from the server:

************************

Hi. This is the qmail-send program at my-server.com.
I tried to deliver a bounce message to this address, but the bounce bounced!

:
Sorry. Although I'm listed as a best-preference MX or A for that host,
it isn't in my control/locals file, so I don't treat it as local. (#5.4.6)

--- Below this line is the original bounce.

Return-Path: <>
Received: (qmail 4417 invoked for bounce); 28 May 2003 08:49:11 -0000
Date: 28 May 2003 08:49:11 -0000
From: MAILER-DAEMON@my-server.com
To: root@ppp148-1.lns1.mel2.internode.on.net
Subject: failure notice

Hi. This is the qmail-send program at my-server.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

:
Sorry, no mailbox here by that name. (#5.1.1)

--- Below this line is a copy of the message.

Return-Path:
Received: (qmail 4414 invoked by alias); 28 May 2003 08:49:11 -0000
Delivered-To: alias-localdelivery-/tmp/nessus_test@upaboveit.com
Received: (qmail 4411 invoked by uid 0); 28 May 2003 08:49:10 -0000
Received: from scanner3.securityspace.com (HELO nessus.org) (216.201.108.30)
  by name.my-server.com (my.server's.real.IP) with SMTP; 28 May 2003 08:49:10 -0000
Your MTA is vulnerable to the 'mailto files' attack

*********************

Any clues as to how one could remedy this?

Another item which was identified (you get a pretty comprehensive report) is this:

smtp (25/tcp)
Remote SMTP server banner :
220 name.my-server.com mailfront ESMTP

This detects the SMTP Server's type and version by connecting to the server
and processing the buffer received.
This information gives potential attackers additional information about the
system they are attacking. Versions and Types should be omitted
where possible.

Solution: Change the login banner to something generic.

Any idea how to change the banner?

Further, there is this:

smtp (25/tcp)

The remote SMTP server seems to allow remote users to
send mail anonymously by providing arguments that are
too long to the HELO command (more than 1024 chars).

This problem may allow malicious users to send hate
mail or threatening mail using your server,
and keep their anonymity.

Clues?

Finally, there is this:

ftp (21/tcp)
Remote FTP server banner :
220 diaboli.upaboveit.com FTP server ready.


This detects the FTP Server type and version by connecting to the server and
processing the buffer received.
The login banner gives potential attackers additional information about the
system they are attacking. Versions and Types should be omitted
where possible.

Solution: Change the login banner to something generic.

Again, clues?

Charles

Re: Security audit on SME server
« Reply #1 on: June 09, 2003, 06:43:09 AM »
Have you tried EnGarde Secure Linux? I've been using it for quite some time now, and it's far more secure than e-smith. Built in crypto, better web management (IMHO) and host and network intrusion detection.

They also use postfix, which is easier to configure antispam protection.

http://engardelinux.org

-chuck

Upaboveit wrote:
>
> I've recently had a security audit done through this place:
> https://secure1.securityspace.com/sspace/index.html
>
> During testing I received this mail from the server:
>
> ************************
>
> Hi. This is the qmail-send program at my-server.com.
> I tried to deliver a bounce message to this address, but the
> bounce bounced!
>
> :
> Sorry. Although I'm listed as a best-preference MX or A for
> that host,
> it isn't in my control/locals file, so I don't treat it as
> local. (#5.4.6)
>
> --- Below this line is the original bounce.
>
> Return-Path: <>
> Received: (qmail 4417 invoked for bounce); 28 May 2003
> 08:49:11 -0000
> Date: 28 May 2003 08:49:11 -0000
> From: MAILER-DAEMON@my-server.com
> To: root@ppp148-1.lns1.mel2.internode.on.net
> Subject: failure notice
>
> Hi. This is the qmail-send program at my-server.com.
> I'm afraid I wasn't able to deliver your message to the
> following addresses.
> This is a permanent error; I've given up. Sorry it didn't
> work out.
>
> :
> Sorry, no mailbox here by that name. (#5.1.1)
>
> --- Below this line is a copy of the message.
>
> Return-Path:
> Received: (qmail 4414 invoked by alias); 28 May 2003 08:49:11
> -0000
> Delivered-To:
> alias-localdelivery-/tmp/nessus_test@upaboveit.com
> Received: (qmail 4411 invoked by uid 0); 28 May 2003 08:49:10
> -0000
> Received: from scanner3.securityspace.com (HELO nessus.org)
> (216.201.108.30)
>   by name.my-server.com (my.server's.real.IP) with SMTP; 28
> May 2003 08:49:10 -0000
> Your MTA is vulnerable to the 'mailto files' attack
>
> *********************
>
> Any clues as to how one could remedy this?
>
> Another item which was identified (you get a pretty
> comprehensive report) is this:
>
> smtp (25/tcp)
> Remote SMTP server banner :
> 220 name.my-server.com mailfront ESMTP
>
> This detects the SMTP Server's type and version by connecting
> to the server
> and processing the buffer received.
> This information gives potential attackers additional
> information about the
> system they are attacking. Versions and Types should be omitted
> where possible.
>
> Solution: Change the login banner to something generic.
>
> Any idea how to change the banner?
>
> Further, there is this:
>
> smtp (25/tcp)
>
> The remote SMTP server seems to allow remote users to
> send mail anonymously by providing arguments that are
> too long to the HELO command (more than 1024 chars).
>
> This problem may allow malicious users to send hate
> mail or threatening mail using your server,
> and keep their anonymity.
>
> Clues?
>
> Finally, there is this:
>
> ftp (21/tcp)
> Remote FTP server banner :
> 220 diaboli.upaboveit.com FTP server ready.
>
>
> This detects the FTP Server type and version by connecting to
> the server and
> processing the buffer received.
> The login banner gives potential attackers additional
> information about the
> system they are attacking. Versions and Types should be omitted
> where possible.
>
> Solution: Change the login banner to something generic.
>
> Again, clues?

Upaboveit

Re: Security audit on SME server
« Reply #2 on: June 09, 2003, 11:07:26 AM »
Charles wrote:
>
> Have you tried EnGarde Secure Linux?

Err, no. "EnGarde Secure Linux Professional: Standard Edition Media Pack List Price: $729" I can buy a lot of beer for $729.........

Ray Mitchell

Re: Security audit on SME server
« Reply #3 on: June 09, 2003, 01:07:05 PM »
Does this help at all ?

http://www.e-smith.org/faq.php3#6q8

Ray

Upaboveit

Re: Security audit on SME server
« Reply #4 on: June 09, 2003, 04:42:01 PM »
Ray Mitchell wrote:
>
> Does this help at all ?
>
> http://www.e-smith.org/faq.php3#6q8
>

No. I had read it and it doesn't address the real problem: mail does get sent. A bounce is attempted that shouldn't be.

Dan Brown

Re: Security audit on SME server
« Reply #5 on: June 09, 2003, 05:49:32 PM »
What version of SME are you running?

Upaboveit

Re: Security audit on SME server
« Reply #6 on: June 09, 2003, 09:23:45 PM »
Currently 5.6U4

Charlie Brady

Re: Security audit on SME server
« Reply #7 on: June 09, 2003, 11:00:27 PM »
Upaboveit wrote:

> I've recently had a security audit done through this place:
> https://secure1.securityspace.com/sspace/index.html

Many "security audits" reveal false positive results.


> Your MTA is vulnerable to the 'mailto files' attack
>
> *********************
>
> Any clues as to how one could remedy this?

You mail server is *not* vulnerable to the "mailto files" attack. As you saw, no file for written to your system, and the mail bounced.


> smtp (25/tcp)
> Remote SMTP server banner :
> 220 name.my-server.com mailfront ESMTP
>
> This detects the SMTP Server's type and version by connecting
> to the server and processing the buffer received.
> This information gives potential attackers additional
> information about the system they are attacking.
> Versions and Types should be omitted where possible.

True, but since there have never been any security vulnerabilities in mailfront, and due to its design, vulnerabilities are unlikely, and limited in the damage they could do, I don't think that's a significant problem.
 
> Solution: Change the login banner to something generic.
>
> Any idea how to change the banner?

Create /var/service/smtpfront-qmail/env/SMTPGREETING containing whatever you want.

> Further, there is this:
>
> smtp (25/tcp)
>
> The remote SMTP server seems to allow remote users to
> send mail anonymously by providing arguments that are
> too long to the HELO command (more than 1024 chars).
>
> This problem may allow malicious users to send hate
> mail or threatening mail using your server,
> and keep their anonymity.
>
> Clues?

False positive. To put it bluntly, the "test" is worth just what you paid for it.

> Finally, there is this:
>
> ftp (21/tcp)
> Remote FTP server banner :
> 220 diaboli.upaboveit.com FTP server ready.
>
> This detects the FTP Server type and version by connecting to
> the server and processing the buffer received.

So can you see the Version number and program name in that FTP banner? I can't.

> Solution: Change the login banner to something generic.
>
> Again, clues?

The test author(s) seems to have insufficient clue(s). :-)

Regards

Charlie