Hi,
We use the Barracuda Web Proxy, and experienced similar issues. After
a whole back and forth and ooh and aah... I have established, and
hacked our Barracuda. Our Internal documentation around this matter
reads:
The short version of it, is that there are Blacklists on the unit
which Barracuda hides, and that no customer has access too. The long
version (and fix) below.
--
Chris.
<SNIP>
Barracuda Hack
Introduction
<removed> uses an Barracuda WebFilter 410 as it's main proxy and web
filter device for the <removed> office. The device offers an high
degree of caching as well as filters and web site classifications,
with Active Directory integration. This puts <removed> in an unique
situation where access to certain web sites can be allowed and denied
to individual users directly from our Active Directory infrastructure,
whilst providing <removed> with advanced security in terms of malware,
phising, and other security concerns out there on the web today.
The Problem
Barracuda Networks supplies 'Energizer' updates to all it's customers
with active subscriptions. The Energizer updates includes web sites
listed in pre-defined categories (such as Streaming Media,
Advertisements, etc) which can in turn be allowed and/or denied access
by the Administrators of the Barracuda WebFilter appliance.
Over time, it has come to the attention of Networks that there are
hidden categories and blacklists applied on all the Barracuda
appliances which cannot be overruled or bypassed by the Administrator
of the device. Effectively, and global block list has been applied
before requests enters the Policy Engine inside the WebFilter where
Administrators can configure policies to allow and/or deny access to
certain web sites.
The matter has been taken up with Barracuda Networks and their stance
was that the blacklists enforced by Barracuda Networks entails web
sites which poses an significant security risk, and as such should not
be given access to under any circumstances. The control of these
blacklists lies solely in the hands of Barracuda Networks, and
<removed> has no way to override any web site inside this blacklist to
allow our staff access thereto. There has also been numerous
complaints from users globally about the accuracy of these web sites,
especially when Barracuda Networks decided to block access to Google!
Accessing the Appliance
Barracuda Networks went through extreme measures to ensure that their
devices remain uncrackable, but it is just Linux and Squid under the
bonnet at the end of the day. BIOS' has been password protected, the
Boot Loaders are password protected, and naturally, you can forget
about shell access on the Appliance directly.
Networks did some research however, and was able to boot the WebFilter
appliance into single user mode, giving unrestricted access to the
Linux OS of the WebFilter device. This hack, should only be required
should the physical appliance be changed, and it should never be
reverted by an Firmware or Energizer upgrade on the Appliance itself.
The only way that I can think of that this change can be reverted, is
possibly by Barracuda Support.
When the Barracuda WebFilter powers up and displays the GRUB boot screen:
- Press 'p' at the boot loader menu to enter the Grub boot loader
password 'bimg'
- Press 'e' on Barracuda to edit the boot loader configuration, and
again 'e' on the second line to edit the kernel options specified
during boot time
- Add 'init=/bin/bash' to the kernel boot options (yes, I know!), and
boot the kernel up. You should now have a bash shell with full root
privileges
- Mount the root partition in order to access the data on disk 'mount
-o remount,rw /'
- Edit /etc/sysconfig/iptables and amend the iptables rules to allow
SSH access. I have merely commented out the REJECT rule rejecting SSH
connections, as the Barracuda WebFilter is already behind our Cisco
ASA Firewall and thus protected.
- Add an user account in the password file using UID 0 and GUID 0.
I've used '/user/sbin/useradd -g 0 -o -p <password> -o -u 0 -d /
systems'. This created an additional account, systems, using / for the
home directory and ensuring root privileges by using UID and GUID 0
- Unmount the file systems, making sure of an clean unmount - or
alternatively sync the filesystems, and then reboot the Barracuda
WebFilter appliance. Once the unit is online, and loaded all of the
Barracuda software, you should be able to connect to the appliance on
port 22 (SSH), and login using the systems account created.
The Hacking Bits
Barracuda's hard coded blacklist works two folded. Firstly, Barracuda
uses iptables' FORWARD, NAT, and MANGLE tables to either block,
divert, or NAT blacklisted IP addresses. Thankfully, on all tables, a
custom chain is created called SPYSITE on the Barracuda WebFilter.
This is Barracuda Networks making live easy for ourselves.
The script created, simply flushes the SPYSITE chain on the FORWARD,
NAT, and MANGLE chains to ensure that there are no DROP or REJECT
rules applied. The chains by default ACCEPTS all traffic so a clean
chain will take care of the bits and pieces that Barracuda Networks
blocks with iptables.
The last part of the hack involves Hemi, the Barracuda Policy Engine
itself. Energizer Updates are checked at apparently random times from
Barracuda's main web site, and if an update is available, it is
immediately downloaded and upgraded on the WebFilter without any human
intervention. The WebFilter is configured to automatically configure
and apply Energizer updates, so I don't really blame Barracuda
Networks for this.
During the debugging, it has been determined that the latest blacklist
in use by the Barracuda WebFilter is always located at
/home/spyware/spydef/current/' which is symlinked to the current
version of Energizer's blacklist in use on the WebFilter. It has also
come to light that Barracuda Networks uses the files called
'cudaredirect-uri.bst.txt' and 'cudaredirect.bst.txt' for their in
house blacklists after searching for a few strings of websites we know
was blacklisted by Barracuda Networks.
Networks has come up with an quick script which takes care of the hard
coded blacklists. The script checks whether the two blacklists in
question was updated by an recent Energizer update. If it was, the
blacklists are backed up, and the content of the current blacklist is
nullified. If the blacklists has been nullified, the script then
proceeds to restart Hemi (the Barracuda Policy Engine) in order for
the blacklist data to be reloaded by the policy engine - this change
is not service affecting at all (again, thanks Barracuda Networks).
Lastly, the script flushes the iptable chains in question to ensure
that no IP level blocks has made it to the SPYSITE chains.
#!/bin/bash
RESTART=0
if [[ `stat -c%s
/home/spyware/spydef/current/cudaredirect-uri.bst.txt` > 0 ]] ; then
/bin/mv /home/spyware/spydef/current/cudaredirect-uri.bst.txt
/home/spyware/spydef/current/cudaredirect-uri.bst.txt.old
/bin/cat /dev/null > /home/spyware/spydef/current/cudaredirect-uri.bst.txt
RESTART=1
fi
if [[ `stat -c%s /home/spyware/spydef/current/cudaredirect.bst.txt` >
0 ]] ; then
/bin/mv /home/spyware/spydef/current/cudaredirect.bst.txt
/home/spyware/spydef/current/cudaredirect.bst.txt.old
/bin/cat /dev/null > /home/spyware/spydef/current/cudaredirect.bst.txt
RESTART=1
fi
if [ $RESTART == 1 ] ; then
/etc/init.d/hemi restart
fi
/usr/sbin/iptables -t filter -F SPYSITE
/usr/sbin/iptables -t nat -F SPYSITE
/usr/sbin/iptables -t mangle -F SPYSITE
Hacking Execution
The script is located in the /scripts directory on the Barracuda
WebFilter. Please note that the script has been set as immutable using
that chattr application. Main reasoning here is that it makes it more
difficult for Barracuda Support to alter and / or remove the file
whether automatically by firmware upgrades, or manually by human
intervention.
Lastly, I have scheduled the script to run every minute via an USER
cron entry ('crontab -u root -e'). Again, this ensures that the
crontab entry is hidden from the obvious locations such as
/etc/crontab, /etc/cron.d, /etc/cron.daily, etc.
The hack now runs once a minute, ensuring that any blocks on iptables
are cleared, and that the blacklist supplied through Energizer updates
are nullified, and the policy engine is reloaded only if the
blacklists has changed.
</SNIP>
On Thu, Aug 16, 2012 at 4:42 PM, Emmanuel Noobadmin
<centos.admin@???> wrote:
> Every so frequently, I get users who complain that their emails are
> getting rejected for unknown reasons by Barracuda. In almost all of
> these cases, no blacklists apart from Barracuda indicates there was
> any spamming/backscatter etc from the server in question. Since
> Barracuda does not provide any hint or info on what/who might be the
> culprit, there's no way for me to check/fix whichever user/domain that
> might be.
>
> The question is, apart from submitting to what amounts to a protection
> racket/extortion in my opinion and paying Barracuda/EmailReg a yearly
> fee to whitelist each and every single one of the server IPs, is there
> any better way to deal with these incidents?
>
> --
> ## List details at https://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/
--
Regards,
Chris Knipe
