Topic: blocking the Zeus botnet using SME at the network perimeter

[smeghead]

I have recently had a couple of clients get caught by a zero day exploit version of the Zeus rootkit/trojan which steals banking info among other things (depending on what a particular release is bundled with); see https://zeustracker.abuse.ch/index.php

After having a dig around the web I found a few suggestions on how to 'automate' adding protections to a Linux system.  I've taken these suggestions & hints (along with iptables help from Contribs, thank guys) & 'rolled my own' extension for SME.  The process needs to download info from the above website on a daily basis & apply the new info to both iptables/masq (the firewall) as well as squid (http proxy).  If either is turned off, as they may be depending on how the server is setup, deployed, & used, then there will be some protection from the other method; no protection if both are tuned off.

This whole process assumes SME is in server/gateway mode.  I also assume you can make your way around the console shell.

I use Midnight Commander as my editor, you can use what works for you.

So, on with the show.  I'll do a step by step:

# Create a script in /root - update_zeus_blocklists.sh

cd /root
touch update_zeus_blocklists.sh

# Edit the file & insert the following into the empty update_zeus_blocklists.sh file

#!/bin/bash
# set -x command used to force echo to screen - comment out or delete line if not required

set -x

cd /root
curl -k https://zeustracker.abuse.ch/blocklist.php?download=iptablesblocklist > iptables_zeus_blocklist.sh
curl -k https://zeustracker.abuse.ch/blocklist.php?download=squidblocklist > squid_zeus_blocklist.txt
chmod +x iptables_zeus_blocklist.sh
# The copy command won't delete the current squid_zeus_blocklist.txt if nothing downloaded
cp -f /root/squid_zeus_blocklist.txt /etc/squid/squid_zeus_blocklist.txt
signal-event proxy-update
/root/iptables_zeus_blocklist.sh

# Create a template fragment in /etc/e-smith/templates-custom/squid/squid.conf

mkdir -p /etc/e-smith/templates-custom/squid/squid.conf
cd /etc/e-smith/templates-custom/squid/squid.conf
touch 45Zeus_blocklist

# Edit the file & insert the following into the empty 45Zeus_blocklist file
# I add a blank line to the top of the file to make the squid.conf file easier to read

acl zeus_blocksites url_regex "/etc/squid/squid_zeus_blocklist.txt"
http_access deny zeus_blocksites

# Rebuild squid.conf

expand-template /etc/squid/squid.conf

Note - don't restart squid yet as the template fragment refers to a file we haven't yet downloaded.

# Edit /etc/rc.d/rc.local to run /root/iptables_zeus_blocklist.sh when server is started

cd /etc/rc.d

# Edit the file & add the following 2 lines at the bottom of the file

# Zeus botnet stuff
/root/iptables_zeus_blocklist.sh

This completes the intial setup, time to run the update script to get the data from the website & deploy it

/root/update_zeus_blocklists.sh

Let's check to make sure it ran as expected.

Look in /root for iptables_zeus_blocklist.sh

Look into the /etc/squid folder & there should now be a squid_zeus_blocklist.txt file

Check the end of the messages log for the proxy-update entries & the squid restart info, you should see something like:

Mar  1 00:38:42 gateway esmith::event[9103]: Processing event: proxy-update
Mar  1 00:38:42 gateway esmith::event[9103]: Running event handler: /etc/e-smith/events/actions/generic_template_expand
Mar  1 00:38:42 gateway esmith::event[9103]: expanding /etc/dhcpd.conf
Mar  1 00:38:42 gateway esmith::event[9103]: expanding /etc/crontab
Mar  1 00:38:42 gateway esmith::event[9103]: expanding /etc/httpd/conf/proxy/proxy.pac
Mar  1 00:38:43 gateway esmith::event[9103]: expanding /etc/squid/squid.conf
Mar  1 00:38:43 gateway esmith::event[9103]: expanding /etc/rc.d/init.d/masq
Mar  1 00:38:43 gateway esmith::event[9103]: generic_template_expand=action|Event|proxy-update|Action|generic_template_expand|Start|1362069522 357568|End|1362069523 489357|Elapsed|1.131789
Mar  1 00:38:43 gateway esmith::event[9103]: Running event handler: /etc/e-smith/events/actions/adjust-services
Mar  1 00:38:43 gateway esmith::event[9103]: adjusting non-supervised masq (adjust)
Mar  1 00:38:44 gateway esmith::event[9103]: adjusting supervised squid (down)
Mar  1 00:38:44 gateway esmith::event[9103]: adjusting supervised squid (restart)
Mar  1 00:38:44 gateway esmith::event[9103]: adjust-services=action|Event|proxy-update|Action|adjust-services|Start|1362069523 489535|End|1362069524 90586|Elapsed|0.601051

You can check to see if the firewall rules have been added by running

iptables -L

It will hit the OUTPUT chain & start to list out a lot of drop rules (this can be quite slow), once I see a few of these I just Ctrl/C the process.  A sample looks like:

DROP       all  --  anywhere             misro.n.masterweb.net
DROP       all  --  anywhere             host-242-8-127-109.azdata.net
DROP       all  --  anywhere             host-246-8-127-109.azdata.net
DROP       all  --  anywhere             vrozetke.com

The last thing to do is to add a cron job (scheduled task) so this update process occurs every day.

I'd suggest using something like http://wiki.contribs.org/Crontab_Manager & using this contrib for the job, otherwise add a template fragment to /etc/e-smith/templates-custom/etc/crontab to suit

cd /etc/e-smith/templates-custom/etc/
touch 99update_zeus

# Edit the file & insert the following into the empty 99update_zeus file

0 04 * * * root /root/update_zeus_blocklists.sh

This will run the script at 4am every day.

Once the template fragment has been created run:

expand-template /etc/crontab
signal-event cron-update

Thats it

Any recommendations/improvements always welcome, as are bugs or typos.

HTH

Graeme

[piran]

You're not 'protecting your linux system'... actually you may
be putting it at an unknown risk. You're apparently attempting
to add some 'protection' for your Zeus-prone users on your system.

http://www.computerworld.com/s/article/9236644/Critical_cURL_library_flaw_could_expose_many_apps_to_hackers?taxonomyId=11&pageNumber=1

Automated access to a remote system to retrieve something
which is then allowed to change your system's configuration
of masquerading and squid. Are you sure that's OK with you?

I haven't worked with squid but I see you are appending OUTPUT
chains for DROPping with iptables (template or otherwise) but you
are only adding lines... they won't take affect unless or until you
reboot the server or restart the masq service.

I used wget to manually retrieve the given stuff. They are
from an AOL IP and consist of lines that are effectively /32
in scope. For any site that already has a good many rules
in use these additional iptables rules just increase the load.
Unnecessarily using /32 lines can get to be 'expensive'...
as all rules (currently) need to be completely parsed each
time. The use of ipset could fix this but it is not included
in our distribution as it has not been included upstream.

My main comment however is the apparent wisdom of
automated access to a remote AOL server and automation
of a reconfiguration of the local server using whatever is
retrieved. Haven't thought it through all that much but it
certainly has raised my eyebrows at the onset of reading...

[smeghead]

Thanks for commenting.

Your first comment is partially valid.  If I haven't checked what I'm downloading, whether it is legit, & if it is valid then I totally agree.  I have checked & tested what I am downloading & it's fine (at the moment), tho if it is modified/changed down the track (maliciously or otherwise) it could be a prob.

The Curl issue, as it relates here, can be summarised by this quote from the web page you nominated:

"The vulnerability can be exploited when a program that uses libcurl or the cURL command
line tool communicates with a malicious server over the POP3, SMTP or IMAP protocols"

In this instance Curl is not using any of these protocols.

The script updates the downloaded squid blocklist file & then restarts squid via the proxy-update event.

I take your point on the /32 (single IP) issue with masq but to use a range instead of a single IP may block a legit site.  All of the servers I run/maintain are a minimum of a dual core P3.0Ghz with 4GB RAM so capable enough to handle the extra processing load.  If your hardware is significantly less than this it could be a prob.  I haven't noticed any speed degradation issues since implementing this addition.

I've not seen IPSET before, this looks like an excellent addition to any Linux system, have you considered posting a New Feature Request in the bugtracker?  That said, in this case, it would require a complete rejig of the downloaded data or maybe a request for the data be made available in this format.

Now the question of the AOL server, this I didn't know, thanks for pointing it out.  I would prefer to avoid any system that is hammered by peeps trying to exploit it, but unfortunately this is where the data is hosted, it certainly reminds me to check the location of what I'm downloading more vigilantly tho.  I suppose I could download the data to my server, run it through my own custom parser to validate the contents, & then make it available from my system .. I'll have a think about it

Thanks again

[piran]

The redirection allowed by cURL might include
an otherwise not included protocol maliciously.

In some spare moments I will spot check some
of those given Zeus /32s against my local
ruleset (10,000+) - out of sheer curiosity;-)

My earlier NFR for IPSET was declined for
the upstream reason previously given.