[BlueOnyx:04712] Re: send mail Relay exploit

Chuck Tetlow chuck at tetlow.net
Mon Jun 7 20:39:46 -05 2010


Oh, I can tell you - they aren't permanent.  The BlueQuartz/BlueOnyx management scripts will rewrite the /etc/sysconfig/iptables rules file each time a new site is added or deleted.  And then it will reload the IP Tables firewalling software after that - using the newly changed rules file.

I've gotten around that somewhat by putting the changes in the /etc/sysconfig/iptables rules file and then making it immutable.  Once that file attribute is set - not even the root user can change that file.  So the management scripts can't change the file and the reload just restarts the firewall.  So, how do you do that?

Edit /etc/sysconfig/iptables.  It will look something like this:

# /etc/sysconfig/iptables
# This file is automatically generated by log_traffic.
# Any manual changes will be lost
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:acctin - [0:0]
:acctout - [0:0]
-A INPUT -j acctin
-A OUTPUT -j acctout
-A acctin -d 216.136.nnn.nnn/32
-A acctout -s 216.136.nnn.nnn/32
-A acctin -d 216.54.nnn.nnn/32
-A acctout -s 216.54.nnn.nnn/32
-A acctin -d 216.54.nnn.nnn/32
-A acctout -s 216.54.nnn.nnn/32
-A acctin -d 216.54.nnn.nnn/32
-A acctout -s 216.54.nnn.nnn/32
-A acctin -d 127.0.0.1/32
-A acctout -s 127.0.0.1/32
COMMIT

Put your new rules in above all the "acctin" rules already there.  Those existing rules allow anyone in with any traffic to those IP addresses, so your block has to go in first to be effective.  Using the previously discussed IPs, it would look something like:

-A acctin -s 41.210.0.0/16 -j DROP

Save the modified file and make it immutable (unchangeable) with the command: "chattr +i iptables" while in the /etc/sysconfig directory.  You can see if the change took effect with "lsattr" command in the /etc/sysconfig directory.  You'll see a little "i" in the list of file attributes in front of the iptables file.

That's it.  Reload IP Tables with "service iptables restart" and your new rule is in effect.  And it won't go away this way.

BUT!  The drawback - if you add another site/IP to your server, the management scripts can't put in a allow for that new IP address.  Ooops!  You've got to manually add it to the /etc/sysconfig/iptables file.  Sorry.  But it does keep your firewall rules you want permanent from being overwritten.

Oh, yea - remove the immutable file attribute with "chattr -i iptables".  Once you've removed that attribute - you can edit/modify the file.

I'll admit - its kinda ungainly.  And believe me - I'd prefer a different method.  Maybe a secondary file in the /etc/sysconfig directory where you could put user-defined firewall rules you want permanent.  And when the BlueOnyx management scripts rewrote the /etc/sysconfig/iptables ruleset - it could put those user-defined rules in first.  But that would be a major change that could only be done by the BlueOnyx group.  Plus, it may not get done because that would start to cut in to the Solarspeed APF/BFD firewall package. 

That's an idea for you Hugo.  If you're uncomfortable with command-line changes to the firewall, you should consider the firewall package from Solarspeed.  Its supposed to detect those username/password guessing attempts and automatically block them.  You wouldn't have to figure out where its coming from and add a firewall rule - it does it for you.

Good luck and I hope that provides some help.

Chuck

---------- Original Message -----------
From: Hugo Sesma <hsesma at gmail.com> 
To: BlueOnyx General Mailing List <blueonyx at blueonyx.it> 
Sent: Mon, 7 Jun 2010 19:48:06 -0500 
Subject: [BlueOnyx:04710] Re: send mail Relay exploit

> Chuk,
> 
> thanks for your info I'm checking to use it with webmin and see if they are permanet
> 
> Regards
> 
> On Mon, Jun 7, 2010 at 6:49 PM, Chuck Tetlow <chuck at tetlow.net> wrote:
> 
> And while you're at it - block their further attempts to find/exploit another username/password.
> 
> The easiest way to do it - block it with IP Tables.  Use this to block that oneI IP:
> /sbin/iptables -I acctin 1 -d 41.210.18.88/32 -j DROP
> 
> But since changing their IP is easy, I'd recommend blocking at least the whole /24 network they are on.  Use
> /sbin/iptables -I acctin 1 -d 41.210.18.0/24 -j DROP
> 
> In my own case, I couldn't care less about e-mails from Ghana.  I'd lock out the entire block of IPs assigned to that country with
> /sbin/iptables -I acctin 1 -d 41.210.0.0/16 -j DROP
> 
> Any of these rules will block further traffic from that IP or their networks.  But remember - this is temporary.  The next time you boot the server, or create a website - IP Tables are reloaded and your temp rule is gone.  Then they're back at your server.  Making the rule permanent is a bit more involved.
> 
> Chuck
> 
> 
> 
> ---------- Original Message -----------
> From: Michael Stauber <mstauber at blueonyx.it> 
> To: BlueOnyx General Mailing List <blueonyx at blueonyx.it> 
> Sent: Tue, 8 Jun 2010 01:25:00 +0200 
> Subject: [BlueOnyx:04707] Re: send mail Relay exploit 
> 
> > Hi Hugo, 
> > 
> > > since friday our server has been exploited as a relay for several domains 
> > > who are spammers 
> > 
> > Do you have SMTP-Auth enabled? If not, enable it. But from what I see it in 
> > your logs it should be on already.  With SMTP-Auth enabled only users 
> > authenticated with their username and password can send emails through your 
> > server. 
> > 
> > > Here is some logs 
> > 
> > >From those log lines only one entry indicates the actual relaying of emails 
> > through your server: 
> > 
> > Jun  7 16:23:14 ns1 sendmail[23694]: o57LMj4U023694: 
> > from=<tbent at wanadoo.co.uk>, size=1509, class=0, nrcpts=50, 
> > msgid=<201006072122.o57LMj4U023694 at ns1.abaco.net.mx>, proto=ESMTP, daemon=MTA, 
> > relay=adsl1888.4u.com.gh [41.210.18.88] 
> > 
> > Someone from the IP [41.210.18.88] sent a 1509 byte large mail to 50 
> > recipients in one go. The line "proto=ESMTP" indicates that he used SMTP-Auth 
> > to authenticate against Sendmail and that was apparently done with a valid 
> > username and password. 
> > 
> > Then the next snippet shows how four of the 50 generated emails were sent out: 
> > 
> > Jun  7 16:23:16 ns1 sendmail[23755]: o57LMj4U023694: 
> > to=<fultonmr at aol.com>,<fultimeslackervb at aol.com>,<fulmoon19 at aol.com>,<fulltipz at aol.com>, 
> > delay=00:00:27, xdelay=00:00:02, mailer=esmtp, pri=1591509, 
> > relay=mailin-02.mx.aol.com. [205.188.155.110], dsn=2.0.0, stat=Sent (2.0.0 Ok: 
> > queued as 3EC3F38000CAD) 
> > 
> > This went to some AOL users in one go. 
> > 
> > So it appears someone has guessed, sniffed or brute forced the login details 
> > of one of your email users. 
> > 
> > How to find out which account that's from? 
> > 
> > Check /var/log/maillog and find the entries immediately above this one: 
> > 
> > Jun  7 16:23:14 ns1 sendmail[23694]: o57LMj4U023694: 
> > from=<tbent at wanadoo.co.uk> [...] 
> > 
> > There should be a line like this: 
> > 
> > Jun  7 16:23:14 ns1 sendmail[XXX]:  AUTH=server, relay=adsl1888.4u.com.gh 
> > [41.210.18.88], authid=USERNAME, mech=PLAIN, bits=0 
> > 
> > That shows "authid=" and the username they used to send the email. 
> > 
> > Or you can use cat and grep to search for it like this: 
> > 
> > cat /var/log/maillog | grep AUTH=server | grep 41.210.18.88 
> > 
> > That searches for "AUTH=server" (which identifies the SMTP-Auth logins) and 
> > for the IP address of the sender of the email. That will return all matching 
> > log entries and the "authid=" part will reveal the compromised username. 
> > 
> > -- 
> > With best regards 
> > 
> > Michael Stauber 
> > 
> > _______________________________________________ 
> > Blueonyx mailing list 
> > Blueonyx at blueonyx.it 
> > http://www.blueonyx.it/mailman/listinfo/blueonyx 
> ------- End of Original Message -------
> 
> _______________________________________________
> Blueonyx mailing list
> Blueonyx at blueonyx.it
> http://www.blueonyx.it/mailman/listinfo/blueonyx
> 
> 
------- End of Original Message -------
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.blueonyx.it/pipermail/blueonyx/attachments/20100607/584f0f2e/attachment.html>


More information about the Blueonyx mailing list