Posts tagged ‘BlueCoat’

Barracuda’s Purchase of Purewire

The 451 Group has a blog entry on the Barracuda’s purchase of Purewire. I am currently evaluating Purewire. This article had some tidbits I hadn’t seen in other analysis.
I had noted that the Security as a Service webspace was getting a bit crowded. ScanSafe as this article notes is the granddaddy of them all. Anyone who uses MessageLabs for email should be checking them out. Webroot has an offering. ZScaler and Purewire are two names I’d come across this year. While it appeared a bit like Purewire latched onto the first warm body they could find, selling early does make sure you aren’t left standing alone at the end of the night.
The 451 Group makes an interesting comment that perhaps BlueCoat would have been a better fit. That would have been very interesting to me. I’m not such a big fan of Barracuda. Venders with radio ads are not targeting infosec people like me. That didn’t turn me off on them so much as the Backscatter they’ve caused with their (previous) default settings.
451 says Purewire has 200 customers. That is beyond small. Larger companies see a lot of web traffic. Even if something were going to escape detection, odds are good that they would be reported by another company first and protection added. Hopefully Barracuda will add more viability than Purewire has currently
451 stated “bake-offs are the exception rather than the rule” in web security. I find that kind of hard to believe. As critical as web traffic is people dont look at multiple venders? Its so easy to set up an eval.
Ultimately my evalutaion of this purchase is “at least its not CA.”

Kaspersky and csshover.htc Possible False Positive?

This morning Kaspersky is detecting Downloader.JS.Iframe.aqo in csshover.htc on a few different websites.
Seems to be a false positive.
Virustotal shows the following:

File csshover.htc received on 04.09.2009 17:40:35 (CET)
Antivirus Version Last Update Result
a-squared 4.0.0.101 2009.04.09 -
AhnLab-V3 5.0.0.2 2009.04.09 -
AntiVir 7.9.0.138 2009.04.09 -
Antiy-AVL 2.0.3.1 2009.04.09 -
Authentium 5.1.2.4 2009.04.08 -
Avast 4.8.1335.0 2009.04.09 -
AVG 8.5.0.285 2009.04.09 -
BitDefender 7.2 2009.04.09 -
CAT-QuickHeal 10.00 2009.04.09 -
ClamAV 0.94.1 2009.04.09 -
Comodo 1107 2009.04.09 -
DrWeb 4.44.0.09170 2009.04.09 -
eSafe 7.0.17.0 2009.04.07 -
eTrust-Vet 31.6.6447 2009.04.09 -
F-Prot 4.4.4.56 2009.04.08 -
F-Secure 8.0.14470.0 2009.04.09 Trojan-Downloader.JS.Iframe.aqo
Fortinet 3.117.0.0 2009.04.09 -
GData 19 2009.04.09 -
Ikarus T3.1.1.49.0 2009.04.09 -
K7AntiVirus 7.10.697 2009.04.08 -
Kaspersky 7.0.0.125 2009.04.09 Trojan-Downloader.JS.Iframe.aqo
McAfee 5578 2009.04.08 -
McAfee+Artemis 5578 2009.04.08 -
McAfee-GW-Edition 6.7.6 2009.04.09 -
Microsoft 1.4502 2009.04.09 -
NOD32 3997 2009.04.09 -
Norman 6.00.06 2009.04.09 -
nProtect 2009.1.8.0 2009.04.09 -
Panda 10.0.0.14 2009.04.09 -
PCTools 4.4.2.0 2009.04.08 -
Prevx1 V2 2009.04.09 -
Rising 21.24.32.00 2009.04.09 -
Sophos 4.40.0 2009.04.09 -
Sunbelt 3.2.1858.2 2009.04.09 -
Symantec 1.4.4.12 2009.04.09 -
TheHacker 6.3.4.0.305 2009.04.09 -
TrendMicro 8.700.0.1004 2009.04.09 -
VBA32 3.12.10.2 2009.04.09 -
ViRobot 2009.4.7.1686 2009.04.09 -
VirusBuster 4.6.5.0 2009.04.09 -
 
Additional information
File size: 4314 bytes
MD5…: 4d50942ad963dd3d0cde4fe42ae1157b
SHA1..: ddb47d9f8d783f8ff1b79527b65ee7e6ac53a359
SHA256: afb97a5d637531616f85cffcd11dd68e7b85f2b5aa01b51b7959dbf2fcf8704c
SHA512: c829e90f6a3669320aec4bb489fb91aa39ed17a85f1584156b5eb8fc32c26b4d
610ede9a8060ce5a82b945930796c7033c55a8e48e7c13a4a179d2aa41b459c0
ssdeep: 96:D+5yu5ugQhnmLzuAX6mLJ3FFD6wB5XhY/l1yYmLXiuiXqwCDGqh:Dju5ugQOF
zLJ3FF5B5S/l1B8XiuiXtCP
PEiD..: -
TrID..: File type identification
Unknown!
PEInfo: -
RDS…: NSRL Reference Data Set
-

UPDATEThis afternoon, I reported the false positive to Kaspersky via a webform. I heard back pretty quickly that this was fixed in the latest defs. Also note Ryan’s entry in the comments.
My problem was compounded a bit becasue the BlueCoat cached the “infected” status, so I needed to clear the cache of that, before csshover.htc could be served.

Caching and Product AutoUpdaters.

I noticed today that Adobe Acrobat 9 Professional wasn’t able to download updates when “Help .> Check for Updates” is selected from within the product. Using Wireshark, I obtained the URLs used to request updates from Adobe. Comparing the results inside my network to those outside of the network, I determined that the BlueCoat proxy on our network had older page cached.
The cached statistics for that page claimed that it had verified with the server that it had a current copy of the file. I blew away the cached content and set swupmf.adobe.com to ‘no cache’. The Adobe Acrobat client was then able to see that updates were necessary.
The Adobe server used eTag. That should have prevented this problem.
Caching can cause issues. When it causes issues with autoupdate mechanisms, would you even notice.

BlueCoat ProxyClient

I’ve been interested in extending HTTP security out to our remote users. When users are in the office their HTTP traffic is antivirus scanned and URL filtered. When remote, they only have desktop antivirus to protect them. As more and more users are mobile, I think it is important to address this.

BlueCoat offers a ProxyClient that can provide traffic acceleration and URL filtering. The URL filtering occurs the same way as with K9 or with a Phishing filter. The URL is sent to their servers and categorized then allowed or blocked accordingly.

Location based rules are created so that acceleration or URL filtering is enabled as appropriate.

I quickly found that the release notes weren’t kidding. SMB signing is incompatible with CIFS acceleration. I was hoping that the traffic would still be accelerated through compression and byte caching. My tests seemed to show that traffic was a bit slower when acceleration was enabled.

What they think I said – what I really said

Have you ever opened a tech support case by calling in, then later reviewed the case via a support web portal? Its kind of funny to see what is lost in the translation.
A couple examples come to mind.
Bluecoat.
I open a ticket asking for help allowing access to gotoassist.com. This is a citrix owned website that is in the gotomeeting, gotomypc family. According to the ticket, I was having a problem going to assist.com.
Symantec
I opened a case asking for help using SecurID to log into Symantec Endpoint Protection Manager (SEPM). They thought I was having a problem authenticating with SecurIZ. That’s right your product uses SecurIZ for authentication not SecurID. No wonder I couldn’t get it working.
These cases were successfully resolved.

The Caching Proxy and the ISP Webmail

Last Friday, one of the guys in the department noticed that when he signed into Cox webmail he would access Cox mailboxes belonging to other employees. He was even able to open messages in those accounts.
I went back to my office and created a test account. There is an awful lot of potential confidentiality violations here. Although I never repeated the results I saw on my co-worker’s screen, I did find I would see the cox inbox for other employees when I selected logoff.
We use BlueCoat SG 810-B to provide HTTP/HTTPS security in web browsing. This additionally provides a proxy cache which in theory saves on bandwidth costs. We haven’t had problems previously with Cox Webmail, nor have we had problems with any other webmail or logon based website.
To resolve the problem, I disabled proxy caching on the BlueCoat for webmail.east.cox.net. Immediately the problem went away.
Just to be on the safe side, I checked with my BlueCoat Sales Engineer. He says that cookie based webmail normally works fine as the cookies are non-cacheable by default. Otherwise the webmaster needs to do a better job marking things a non-cacheable. By marking the entire site as non-cacheable I resolved the problem quickly.

Blue Coat DRTR adds anti-phishing capability

Blue Coat announced today that its Dynamic Real-Time Rating (DRTR) will now catagorize phishing sites on the fly in addition to pornography and gambling sites. DRTR is used to catagorize previously uncatagorized sites.

The Day the Internet Traffic Stood Still

On Thursday we rolled out the Blue Coat web filter to the company. It was a bit more sudden than I had planned. I had planned to roll out slowly over a week and a half (still kind of quick), with the goal to be done by January 28th. Our Websense license expired on January 31st and I wanted to be done before then.
Unfortunately a company board meeting interfered in my plans as we were not allowed to roll out anything while they were in town. I was told that after license expiration, Websense would continue to filter, but not get any new updates. This was acceptable to the Director, so we pushed back the Blue Coat with a new goal of February 5th.
As it turned out at 11 pm on January 31st Websense stopped filtering. So on the morning of the 1st we rolled out Blue Coat to the entire company and disabled the Websense.
That afternoon, I received a report about slow FTP to our DMZ. I did some testing and the speed seemed reasonable. However, that wasn’t the end of it.
The next morning before I got to work, I had a voicemail about other people having trouble opening Flash and downloading large pdf files from the DMZ. It came to a head when another Director in our company emailed our Director claiming it was impossible to get any work done. The Director wanted to turn it off all together, but I felt that this would not provide a good troubleshooting environment. We had used Blue Coat within our department with no reported problems of this nature, so we needed to have the systems under close to a full load. A compromise was reached by removing the subnets of the complainers from filtering.
The network guys had already opened up cases with Cisco and Blue Coat. Everything appeared to be normal. The configuration was acceptable to the support people. The CPU and RAM seemed fine.
I checked the antivirus appliance to make sure it wasn’t running out of threads, but everything was well within spec there. Next, I checked the Blue Coat forums to see what other people had to say about this problem.
A quick check found that the most likely cause was mismatched speed or duplex issues on the switch. I called one of the network guys as 1:45 to ask him to check into that. I kept searching to get an idea of other things to try (and also establish some speed test baselines). A speed test reporting downloads of 800 kbps. Which is ludicrous when we have a 25 meg pipe.
We checked into the switch and found it wasn’t quite as intelligent as we had expected. We didn’t have the capability to hard code the connections to a specific speed and duplex value. We did however see the collision light was occurring on the connection to the core router. I should mention the switch is 10/100/1000 and the router interface is 100. We checked the router and saw the same errors there. The connection was already hardcoded to 100 Full so the network guys changed that to auto. That’s the opposite of what you normally do when you have this problem. The port negotiated 100 Full and the errors went away.
I performed a few speed tests and found that web requests were benchmarked 10-100 times faster. The speed test now reported something crazy like 80 meg down (due to the antivirus or caching I suspect). But it is at least and apples to apples comparison with the 800 kb test.
So all is solved. The problem was not with the Blue Coat, but I did take a few body blows and get a black eye.

Bluecoat Testing

On Friday, I ran into an issue with my Bluecoat evaluation. Bluecoat is an HTTP security and caching company.
One of our developers couldn’t connect into a Webex session with an external company. So my time, the developers time and the external companies support time was wasted. I would have solved the problem quickly, but I thought I had used WebEx through Bluecoat successfully. I found if I disabled antivirus scanning going to the WebEx website that I was able to connect to webex meetings.
It seems to me that if Bluecoat as widely used as they claim, this would be a well known problem. Its not listed in their KB, and my pre-sales support guy only came back with what I said to him, “if I disable antivirus it works.” Shouldn’t they provide a list of known issues so I can preconfigure my proxy appropriately and not have to stumble into these problems? Better yet, find out why the problem occurs so I dont have to bypass AV when going to webex.com.

Thomas Shinder’s Anti-Bluecoat Rant

Thomas Shinder attempted to rebut a Bluecoat webcast in this blog entry from February. In their Webcast, Bluecoat apparently presented the results on a report from Broadband-Testing comparing ISA and Bluecoat in the area of HTTP security. Mr. Shinder clearly has a dog in the fight since apparently makes his living writing ISA books, as an MVP in ISA, and moderating on isaserver.org. Looking at his other posts, he really has it in for Bluecoat. I’m not sure why.
I have used ISA 2000 and 2004 and am currently testing a Bluecoat appliance. I have read the Broadband-Testing document and I’ve probably seen the webinar he references.
Lets take it by the numbers. According to Shinder, Bluecoat asserts:
1. Bluecoat is more secure because its built on the SGOS rather than a Windows OS that needs constant patching.
I would say the SGOS is security through obscurity. However, its not going to be used as a firewall so it shouldn’t be held to the same standard as ISA. The bottom line is however, that with ISA you could be patching the OS monthly. Not so with Bluecoat.
2. ISA cant content inspect SSL traffic
Here, Shinder knows what they are talking about but misdirects the issue into that of content inspection of traffic that is reverse proxied (external to internal). The real issue is that if I’m behind an ISA firewall, my SSL traffic goes straight out. Bluecoat can play man in the middle and intercept SSL traffic and perform content inspection and antivirus. This becomes important as more and more traffic is sent over SSL.
From another one of Shinder’s articles it does appear that there is an add-on product for ISA that would compete with Bluecoat in this area.
3. ISA is unable to manage P2P and IM
Hinder answers as if the issue is blocking P2P. The idea is manage it. Does Bluecoat do as good a job as Akonix, Symantec, et al? No they don’t, but they certainly do more than ISA.
4. ISA has limited access control
I’m not really qualified to compare the depth and breadth of access control options. I think ISA’s control options are geared to the firewall not to http controls.
5. Performance
Shinder attacks the external study claiming the ISA server must have been mis-configured to attain such results.
The bottom line for me is that ISA works great at protecting OWA servers and allowing remote employees to access email. However, its not a great HTTP security system without a bunch of add-ons. Those add-ons just ultimately create a kludge rather than a solution.
Check out the comments from Shinder’s post. Its hard to tell who is actually the 18 year old kid the commenter named anti-Shinder or Shinder himself.