Mail services checking - URGENT

Jeremy Chadwick koitsu at FreeBSD.org
Mon Sep 8 13:20:26 UTC 2008


On Mon, Sep 08, 2008 at 05:59:54AM -0700, David Southwell wrote:
> On Monday 08 September 2008 05:19:51 Jeremy Chadwick wrote:
> > On Mon, Sep 08, 2008 at 05:10:27AM -0700, David Southwell wrote:
> > > I have had a series of attacks on a system which resulted in a hijack of
> > > our mail system.
> > >
> > > I believe I have now fixed the main problem but I need a tool that will
> > > reliably, and independently of the mail logs check my network for all
> > > outgoing mails and hold them up until I am certain that there all
> > > loopholes have been closed.
> > >
> > > Can anyone please let me have some recomendations on the best way of
> > > going about this
> >
> > I'm not sure what exactly you want.  Someone compromising your system
> > means they could've done *anything*, including running their own MTA,
> > replacing libc to include an open proxy for spamming, or any other
> > thing.  There's no way to "detect" that sort of thing aside from deep
> > packet inspection to look for mail-like network traffic, which is
> > predominantly the job of a router or network tap.  It's going to be
> > impossible for you to 100% ensure the system is in a working state.
> 
> What happened was compromising 2 windows systems and installing a trojan on 
> those two systems. They were used to send mail via the MTA's on the freebsd 
> server to the outside world and in particular permissions to send mail to 
> root on the freebsd server.
> 
>  There was no actual compromise of the freebsd server and the windows systems 
> had no ability to access the server. 

Okay, in that case you can disregard my comments about formatting the
FreeBSD machine.  Instead, format the Windows machine.  ;-)

> > Keeping it simple, making the (horrible) assumption that they
> > compromised something that affected your MTA: it depends completely an
> > entirely on what MTA you're using (sendmail, postfix, etc.).  See the
> > your MTA's manpages for looking at outbound/delivery mail queue.
> 
> In addition to the above I am loking for an additional way of monitoring smptd 
> 25 outbound traffic at the network level, filter the traffic, and do an extra 
> checks to make sure there is nothing left when I reopen the service to the 
> local network.

You didn't disclose what MTA you're using on the FreeBSD box.

On postfix, you should use the 'mailq' command.  I believe sendmail also
uses 'mailq', but requires specific arguments to examine the outbound
queue.

Regarding monitoring TCP port 25 traffic: I'm not sure what you mean by
"monitoring".  You should be able to tail logfiles, or use tcpdump to
monitor those packets: tcpdump -p -l -n "tcp and port 25"

Regarding blocking outbound SMTP traffic (traffic your MTA is sending to
mail servers on the Internet), you should be able to use pf to block
that.  These rules, in this order, in /etc/pf.conf should suffice and
should not affect existing IP traffic or lock you out (but I HIGHLY
recommend you apply these over serial or VGA console -- doing in-band
firewall changes is a very, VERY risky/bad idea):

pass in all no state
pass out all no state
block in quick on <interface> proto tcp from <mailserverIP> to any port 25

Replace '<interface>' with the network interface used for this traffic,
and '<mailserverIP>' with the IP of your mail server.

(For readers: the reason I'm telling him to use "no state" is that I
don't want to bother getting into a discussion about pf state tracking
and "oh man suddenly my SSH connection died to the box" or other things
which are expected but require explanation.)

Enable pf by using this in /etc/rc.conf:

pf_enable="yes"

Then run "/etc/rc.d/pf start".  I'm making the assumption you have pf in
your kernel, or that it will load as a kernel module successfully.  If
you get a warning about ALTQ (traffic flow/shaping) not working, you can
ignore it.

> > By the way, and I apologise if I'm stepping over a line here, but "fixed
> > the main problem" doesn't sound like you fixed anything.  You might have
> > "addressed the hole they used to get in on", but what makes you think
> > they didn't replace binaries (including using touch -amcf to adjust
> > a/m/ctimes) or do something even more sneaky?
> 
> The main problem was the trojan and stuff that it brought in. Hefty use of 
> Kaspersky and about six other tools on the windows systems has  resolved the 
> issue. I have not been able to detect any attempts from the windows systems 
> to abuse the mail system but I want to monitor dynamically for some time.

I still wouldn't trust it, and it has nothing to do with it being
Windows.  Members of the FreeBSD security team would likely provide the
same advice ("format the disk and reinstall the OS entirely").  This
concept applies universally.  You have even less visibility into the
inner workings of a Windows box than you do a *IX box; it's just the
nature of the beast.

Otherwise, "congratulations", assuming this is your first encounter
dealing with hackers.  :-)

-- 
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |



More information about the freebsd-ports mailing list