technology, networking and IP telephony
BlueCoat
Packet Capture on a Blue Coat ProxySG Appliance
0December 8, 2010
A large number of colleagues recently had their leased laptops refreshed with a new model and they chose to install Windows 7, a decision which I can’t really fault. Unfortunately as with many things these days we quickly found a few issues, one of which was with Microsoft’s Live Messenger and our Blue Coat ProxySG appliances. I almost immediately suspected the Blue Coat ProxySG appliance so I decided to look there first.
I started with a quick packet capture on the Blue Coat ProxySG appliance. I logged into the appliance and setup a filter to capture just the traffic to/from the IP address of my laptop. Our proxy servers have thousands of clients utilizing them at any one time so trying to perform a packet capture without a filter would be equivalent to trying to take a drink of water from a fire hydrant.
[root@linux ~]# telnet proxy.acme.org Trying 10.1.2.100... Connected to proxy.acme.org (10.1.2.100). Escape character is '^]'. Using telnet exposes your password. Using ssh is a safer choice. Username: admin Password: ******** SG800>enable Enable Password: ******** SG800#pcap filter expr "host 10.1.1.2" ok SG800#pcap start ok
With the packet trace running I went about duplicating the problem from my laptop.
SG800#pcap stop ok SG800#pcap info packet capture information: Packets captured: 76 Bytes captured: 9034 Packets written: 76 Bytes written: 11290 Max packet ram: 0 Packet ram used: 0 Packets filtered: 6113 Bridge capture all: Disabled Current state: Stopped Filtering: On Filter expression: expr "host 10.1.1.2" SG800#pcap transfer ftp://ftp.acme.org username password ok
I retrieved the packet capture from the FTP server and used WireShark to examine the data. The packet trace showed the proxy server sending a RST packet closing the connection to the SOCKS port.
Another trick I learned a long time ago with the ProxySG appliances; try https://proxy.acme.org:8082/SYSInfo (you should obviously replace the hostname in the preceding URL if you want to try it out on your ProxySG appliance). In the IM debug information I found the following reference;
6983.574 MSN 5523C010: Can't proceed with unknown version: MMSG-VER-MSNP18 6983.574 MSN 5523C010: VER: MMSG-VER-MSNP18 not supported 6983.560 Admin: Accepted SOCKS client connection from 10.1.1.2 (policySession: 3895168, socksTrans: 7B5A004)
The log entries above suggest that this latest version of the Live Messenger is using a protocol version that isn’t yet supported by the Blue Coat ProxySG appliance, or at least isn’t supported in the 4.3.x software branch. I did a quick Google search and found a relative knowledge-base article on Blue Coat’s website that provides all the details around which IM versions are specifically supported on which ProxySG software releases. There is an option to just tunnel the SOCKS connection which I’ll need to investigate.
Cheers!
Blue Coat ProxySG Appliance – test http url
4August 18, 2010
We recently had an issue where a few of our Blue Coat ProxySG appliances were having issues connecting to a specific URL. We would continually get the “TCP Error” banner from the Blue Coat proxy servers trying to connect to this website. We had no issues connecting directly (outside of the ProxySG appliances) so the proxy servers were assumed to be the immediate suspect in the problem.
Thankfully there’s a way to quickly and easily test access a specific URL from the CLI interface of the Blue Coat ProxySG appliances.
SG800#test http get ? <url>
So I performed a quick test from the CLI interface;
SG800#test http get http://someurlsomewhere.com Type escape sequence to abort. Executing HTTP get test * HTTP request header sent: GET http://someurlsomewhere.com HTTP/1.0 Host: someurlsomewhere.com User-Agent: HTTP_TEST_CLIENT * HTTP response header recv'd: HTTP/1.1 503 Service Unavailable Cache-Control: no-cache Pragma: no-cache Content-Type: text/html; charset=utf-8 Proxy-Connection: close Connection: close Content-Length: 1329 Measured throughput rate is 0.03 Kbytes/sec HTTP get test passed
It was easy to immediately see that the web server was returning a 503 error to the proxy server, something that was impossible to see from the client browser and difficult to locate from the log files.
The hosting company for the server in question eventually resolved the issue when they removed the automatic blacklisting that had been automatically placed on the proxy server’s public IP address after too many people failed to authenticate properly (because the website in question had a password on it).
Here’s the test when it worked properly returning a 401 error requiring the user to authenticate;
SG800#test http get http://someurlsomewhere.com Type escape sequence to abort. Executing HTTP get test * HTTP request header sent: GET http://someurlsomewhere.com HTTP/1.0 Host: someurlsomewhere.com User-Agent: HTTP_TEST_CLIENT * HTTP response header recv'd: HTTP/1.1 401 Authorization Required Date: Wed, 11 Aug 2010 15:40:31 GMT Server: Apache/2.2.3 (CentOS) WWW-Authenticate: Basic realm="For Acme Health only..." Content-Type: text/html; charset=iso-8859-1 Cache-Control: proxy-revalidate Content-Length: 479 Connection: close Proxy-support: Session-based-authentication Measured throughput rate is 4.50 Kbytes/sec HTTP get test passed
Cheers!
Internet Utilization at 99.9% Arrgghhh!
0June 24, 2009
I thought I would just share this short story with you all… it’s a classic case of what can happen even with the best of plans and intentions. We recently deployed Adobe Acrobat Reader 9.1.2 via Microsoft Active Directory Group Policy.
We rushed the deployment in order to address some of the recent Acrobat vulnerabilities that were being actively exploited in the wild by Nine-Ball and other trojans/malware. We noticed an unusual uptick in Internet utilization almost immediately after the package had been deployed. When we examined our Websense logs we found an extreme number of HTTP requests to swupd.adbobe.com. We determined that these requests were coming from Adobe software products that were attempting to check for an update via Adobe’s auto-update feature. The HTTP requests were being denied by our Blue Coat ProxySG appliances because we require user authentication to access the Internet. While the Adobe auto-update component was able to read the PAC file configured within Internet Explorer it was not able to provide authentication when challenged with a 407 response. We originally thought the sheer number of clients making requests was putting an undo burden on the system so we added some CPL code to our Blue Coat ProxySG appliances to allow non-authenticated access to *.adobe.com. Within minutes of that change the wheels on the bus came flying off literally.
We just happen to have two 50Mbps Ethernet links to the Internet being served from two Blue Coat ProxySG appliances with about 5,500 client PCs. Within minutes both ProxySG appliances went to 96% CPU utilization and both Internet links went to 99.9% utilization. We had literally let the cat out of the bag and it was off and running… the number of client PCs trying to download updates from Adobe surged and they literally started to choke our two Internet connections.
Thankfully the Blue Coat ProxySG appliances support bandwidth classes. We created a 1Mbps class and added some CPL code to bandwidth restrict access to *.adobe.com. While that proved to be the quick fix we’re also deploying an update via Group Policy to disable the auto-update feature per Adobe’s knowledgebase article.
Cheers!
