Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: exim: users

Best method to deal with rejects by Barracuda?

 

 

exim users RSS feed   Index | Next | Previous | View Threaded


centos.admin at gmail

Aug 16, 2012, 7:42 AM

Post #1 of 10 (2235 views)
Permalink
Best method to deal with rejects by Barracuda?

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/


savage at savage

Aug 16, 2012, 7:55 AM

Post #2 of 10 (2214 views)
Permalink
Re: Best method to deal with rejects by Barracuda? [In reply to]

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 [at] gmail> 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

--
## 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/


graeme at graemef

Aug 16, 2012, 8:49 AM

Post #3 of 10 (2179 views)
Permalink
Re: Best method to deal with rejects by Barracuda? [In reply to]

On Thu, 2012-08-16 at 16:55 +0200, Chris Knipe wrote:
> 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.

<snip>

Very interesting, but not relevant to this mailing list. Please keep
further discussion of this specific matter off the Exim Users mailing
list.

Thanks,

Graeme
(obo. mailing list moderators)


--
## 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/


wbh at conducive

Aug 16, 2012, 5:11 PM

Post #4 of 10 (2173 views)
Permalink
Re: Best method to deal with rejects by Barracuda? [In reply to]

Emmanuel Noobadmin 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?
>

There does not have to BE a 'culprit' under your control.
Foolish or lazy admin at their end serves just as well.

What works for me for Donkey's Years now is to bothway-LBL such servers
as-encountered.

Anyone in the user-community behind such servers WILL also have a gmail,
yahoo, or wotever account. They have to.

They can use that to correspond with your users.

End of problem.

Bill
--
韓家標


--
## 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/


centos.admin at gmail

Aug 17, 2012, 3:56 AM

Post #5 of 10 (2177 views)
Permalink
Re: Best method to deal with rejects by Barracuda? [In reply to]

On 8/16/12, Chris Knipe <savage [at] savage> wrote:
> 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.

Thanks for the detailed reply, although it is not relevant to my
question since I don't (and won't ever) run a Barracuda device in any
place I have a say about. The problem is with people using Barracuda's
devices and causing problems for my users for no fault whatsoever that
I can identify.

My question is more towards whether there is a way to configure exim
somehow to get around the Barracuda blacklist, such as maybe rewriting
headers or consolidating all outgoing emails via some intermediate
proxy within my network.

--
## 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/


centos.admin at gmail

Aug 17, 2012, 3:59 AM

Post #6 of 10 (2179 views)
Permalink
Re: Best method to deal with rejects by Barracuda? [In reply to]

On 8/17/12, W B Hacker <wbh [at] conducive> wrote:
> There does not have to BE a 'culprit' under your control.
> Foolish or lazy admin at their end serves just as well.

That is true too, I had clients who get blocked because their modem
just got handed a dynamic PBL IP that Barracuda blacklisted.

> What works for me for Donkey's Years now is to bothway-LBL such servers
> as-encountered.

Sorry but googling didn't give up a relevant meaning of LBL. What is
it and how is that configured in exim?

> Anyone in the user-community behind such servers WILL also have a gmail,
> yahoo, or wotever account. They have to.
>
> They can use that to correspond with your users.
>
> End of problem.

Currently, that is what I tell my users as well as affected clients to
do but paying customers tend to be a little annoyed about having to do
that and often their tone indicates they think we're the one not doing
the proper thing.

--
## 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/


duihi77 at gmail

Aug 17, 2012, 4:37 AM

Post #7 of 10 (2175 views)
Permalink
Re: Best method to deal with rejects by Barracuda? [In reply to]

On Friday, August 17, 2012 at 10:59:24 UTC, centos.admin [at] gmail confabulated:

> On 8/17/12, W B Hacker <wbh [at] conducive> wrote:
>> There does not have to BE a 'culprit' under your control.
>> Foolish or lazy admin at their end serves just as well.

> That is true too, I had clients who get blocked because their modem
> just got handed a dynamic PBL IP that Barracuda blacklisted.

And more than likely was the result from the Barracuda having the
deep header parsing turned on.

>> What works for me for Donkey's Years now is to bothway-LBL such servers
>> as-encountered.

> Sorry but googling didn't give up a relevant meaning of LBL. What is
> it and how is that configured in exim?

>> Anyone in the user-community behind such servers WILL also have a gmail,
>> yahoo, or wotever account. They have to.
>>
>> They can use that to correspond with your users.
>>
>> End of problem.

> Currently, that is what I tell my users as well as affected clients to
> do but paying customers tend to be a little annoyed about having to do
> that and often their tone indicates they think we're the one not doing
> the proper thing.

--
If at first you don't succeed...
...so much for skydiving.


--
## 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/


wbh at conducive

Aug 17, 2012, 5:51 AM

Post #8 of 10 (2172 views)
Permalink
Re: Best method to deal with rejects by Barracuda? [In reply to]

Emmanuel Noobadmin wrote:
> On 8/17/12, W B Hacker <wbh [at] conducive> wrote:

>
> Sorry but googling didn't give up a relevant meaning of LBL. What is
> it and how is that configured in exim?
>

Local Black List as opposed to Remote Black List.

EG: 'LBL' is the one you do not have to make an off-box remote call to
search.

It, or 'they' are 'configured' however, and to act whenever and,
wherever, or multiples of such - as you see fit.

You do use Local White Lists do you not?

Just reverse the acl verb action. ELSE 'NOT' the conditional.

As always, test first with a 'warn' class verb with:

logwrite = <some relevant identifier>
(the clause is being traversed at all, not skipped)

and

log_message = <some associated, but not identical identifier>
(acl conditional actually 'fired')

... to confirm it works as expected before switching it on for production.

Comment them off or replace with something more appropriate after proven
in use.

Bill

--
韓家標



--
## 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/


david at ols

Aug 17, 2012, 7:15 AM

Post #9 of 10 (2176 views)
Permalink
Re: Best method to deal with rejects by Barracuda? [In reply to]

Hi

> That is true too, I had clients who get blocked because their modem
just got handed a dynamic PBL IP that Barracuda blacklisted.

i had the same problem, which was also discussed here some time ago, and
one easy
solution is just remove the ip address of authenticated users in the
received header
added by exim like if the message was locally submitted:

received_header_text = Received: \
${if and {{def:sender_rcvhost}{!def:authenticated_id}}\
{from $sender_rcvhost\n\t}\
{\
${if def:sender_ident {from ${quote_local_part:$sender_ident} }{\
${if def:authenticated_id {from
${quote_local_part:$authenticated_id} }}\
}}\
${if def:sender_helo_name {(helo=$sender_helo_name)\n\t}}\
}\
}\
by $primary_hostname \
${if def:received_protocol {with $received_protocol}} \
${if def:tls_cipher {($tls_cipher)\n\t}}\
(Exim $version_number)\n\t\
${if def:sender_address \
{(envelope-from <$sender_address>)\n\t}}\
id $message_exim_id\
${if def:received_for {\n\tfor $received_for}}

--
Best regards ...

----------------------------------------------------------------
David Saez
On-Line Services 2000 S.L.
http://www.ols.es
----------------------------------------------------------------



--
## 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/


Chris.Knadle at coredump

Aug 17, 2012, 11:26 PM

Post #10 of 10 (2164 views)
Permalink
Re: Best method to deal with rejects by Barracuda? [In reply to]

On Thursday, August 16, 2012 10:55:35, Chris Knipe wrote:
> 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.

I think Chris's point concerning Barracuda is that fixing the blocklist
problem it comes with by default requires a rediculous effort that requires
going well outside the normally configurable features. This at least lets us
know that it may not be the fault of the owner of the Barracuda box, and if
you end up administering one how you can get around the problem. [.It also
serves as a warning against using Barracuda as an anti-spam solution.]

I think these were useful things to know, so even though it may have been
technically off-topic I'm glad to have the information.

-- Chris

--
Chris Knadle
Chris.Knadle [at] coredump

--
## 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/

exim users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.