On Fri, 10 Jan 2003, Andy Kirk wrote:
> I was until about an hour confident that my SMTP relay was secure. At that
> time, I received a spam email promoting 1,000,000 email address, that
> appears to have been sent from my mail server. At least, the From says
> [EMAIL PROTECTED], and from looking at the headers, the from address
> also contains a secondary email address from yahoo. The user portion of the
> email, is a random generated name that does not exist on my server.
> 1. Is it possible for someone to basically use my relay to send mail to my
> domain
1) It is possible but the From field is not a good indicator of if that
happened. The From field can contain ANYTHING with or without passing
through your server. Anotherwords, the From field can contain your host
address and never have touched your server at all. The only way to stop
such a problem would be to modify the SMTP standard to required digitally
signed From fields.
> 2. Is there anyway to test if this is possible
2) Yes, the Received field is a much better indicator because it can
usually be confirmed or denied via your logs. Take the following which
was added to the message you sent the RH mailing list:
Received: from server.circulation-solutions.net
(195-74-107-70.adsl.entanet.co.uk [195.74.107.70])
by mx1.redhat.com (8.11.6/8.11.6) with SMTP id h0AMI2B08139
for <[EMAIL PROTECTED]>; Fri, 10 Jan 2003 17:18:03 -0500
Here the administrator of mx1.redhat.com can see that the header of the
email claimed that his (or her) machine accepted an email from
195.74.107.70 (and the resolution of address at the time of connection).
The "server.circulation-solutions.net" is what was given at the time the
HELO or EHLO was provided during the SMTP transaction.
The SMTP id and the date (in this case "h0AMI2B08139" and "Fri, 10 Jan
2003 17:18:03 -0500") would have been added by mx1.redhat.com if the
Received line is valid. This is helpful because even if the "Date" field
is purposily or accidently incorrect or even if mx1.redhat.com has been
running with an incorrectly set clock, the Received line still gives an
indication where to look in the logs. Also, the SMTP id should have been
added by mx1.redhat.com itself and have a matching reference in the logs.
The default on RH 8.0 is to put MTA (Sendmail, postfix, etc.) syslog
information into /var/log/maillog and to rotate the logs once a week on
Sunday at 4am. So, if we are checking the validity of the above Recieved
line on Jan 10 or Jan 11 then we would look in /var/log/maillog. If we
wait until Monday, Jan 13 then we would look in /var/log/maillog.1 The
quickest way to find a matching entry is to simply grep for the SMTP id in
the approbate log file. If we find a matching entry then the email
probably did go through the server just as the Received line claims. If
there is not match then the Received line might have been forged (or your
logs are truncated/incomplette).
If no such Recieved line exists then there is not even the claim in the
header that it passed through your server and your probably simply dealing
with a forged From field.
> 3. Is there anyway to stop it, whilst still allowing email destined for my
> domain to be received.
3) Again, if the problem is a forged From field, these not really an easy
solution to stop it. You can try to push the IETF to promote digital
signature checking as a revised SMTP standard but that would probably make
for a long wait. If it is a true SMTP relay issue then it is just a
matter of correcting your configuration file. Red Hat 8.0 now distributes
both BSD Sendmail and Postfix. I find the learning curve to working with
the Postfix configuration file to be much lower. If you choose to use BSD
Sendmail then I highly recommend getting the famous O'Reilly Sendmail book
(with the bat on the cover). If you choose to switch from Sendmail to
Postfix then keep the following in mind:
3A) RH 8.0 now uses the Debian alternatives system, use:
/usr/sbin/alternative --config mta
also remember to check /sbin/chkconfig --list to make sure the right MTA
will be started on boot.
3B) Postfix will not deliver email that Sendmail has queued as deferred.
To process old deferred email, you should run:
/usr/sbin/sendmail.sendmail -q1h
3C) Postfix has a history of being secure and several of the postfix
modules run in RH 8.0 with the additional security of being chroot'ed.
But *if* a security problem where to occur, RH has indicated with it's
handling of the CUPS remote root vulnerablity that they are willing to
leave security issues with "non-default" packages unresponded to for
weeks. It is clear that RH considers Sendmail, not Postfix, to be the
default package when it comes to RH 8.0. In the case of CUPS, even if you
use up2date today (11 Jan 2003), a vulnerable version is still left
installed. It seems clear that if there is a security problem with the
default package (LPRng or Sendmail) then RH will attempt to be more
responsive.
--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe
https://listman.redhat.com/mailman/listinfo/redhat-list
