The proxy is the ideal place to have an object cache. This should make sense intuitively. You have multiple users accessing the internet from the same location. Many of them will go to the same web sites, so caching objects from those sites locally, means more bandwidth available to all users to access the internet. It also means faster access for users to content when their requests match objects already in the cache. Objects can be anything stored on a web page, documents, images, video, or audio files.
For objects that aren't a cache hit (a first time visit by any user to a website), pipelining can help speed up access to that page. By retrieving objects in parallel instead of serially (where you have to wait for one object to finish loading before fetching the next), you can load the contents into the cache and the destination browser much more quickly than a traditional fetch.
Object caching does have its denigrators. Depending on the implementation, object caches have been criticized for containing stale data. In today's on-demand 24x7 world, having the up-to-the-minute information is key. Likewise, your object cache needs to have algorithms that help it detect when data changes. Technologies like adaptive refresh, keep track of the types of data in an object cache, and can determine based on the data type how often that data type is likely to change, and check the server for "freshness" of the data, even if there hasn't been a recent request for that data.
With the right proxy there's no reason not to have an object cache and all the benefits of caching. Look for adaptive refresh and pipelining to help speed your internet access.
Tuesday, June 17, 2008
Monday, June 16, 2008
Malware Threats Move from Email to the Web
Just a few years ago, the biggest concern for most IT administrators was viruses coming into their organization's networks via email attachments. The unwary user would click on an attachment and install a virus on their computer, doing damage to their own computer and to the local network.
Today, these viruses and worms still exist, but their threat is relatively mitigated with the prevalence of anti-virus scanners on the edge of the network, on servers and on desktops.
As hackers realize this, they've moved their attacks to areas that have less security, specifically web sites that employees have access to. In addition, attacks have become more targeted and in smaller volume. URL's of websites that have malicious content are now emailed to specific targets with personalized emails. Recently, an attack targeted only 500 executives, rather than the widespread mailings administrators are accustomed to with spam. While this one contained a payload, a more recent attack targeting workers at Berkeley Lab targeted employees by asking them to divulge personal information at a website.
What's an IT administrator to do about all these targeted attacks? First, make sure all your anti-virus and anti-malware software is up to date. Second, make sure your users are familiar with phishing and know to check the actual URL's before clicking on any URL's in an email message. Finally make sure you have a security device like a proxy, that knows sites that contain malicious content and blocks those sites. In recent attacks of well known websites, the URL databases of the best proxies had the malicious websites (the URL's embedded into the well-known sites to cause harm) already categorized as malicious and blocked their access by end-users (who were behind the proxy).
Today, these viruses and worms still exist, but their threat is relatively mitigated with the prevalence of anti-virus scanners on the edge of the network, on servers and on desktops.
As hackers realize this, they've moved their attacks to areas that have less security, specifically web sites that employees have access to. In addition, attacks have become more targeted and in smaller volume. URL's of websites that have malicious content are now emailed to specific targets with personalized emails. Recently, an attack targeted only 500 executives, rather than the widespread mailings administrators are accustomed to with spam. While this one contained a payload, a more recent attack targeting workers at Berkeley Lab targeted employees by asking them to divulge personal information at a website.
What's an IT administrator to do about all these targeted attacks? First, make sure all your anti-virus and anti-malware software is up to date. Second, make sure your users are familiar with phishing and know to check the actual URL's before clicking on any URL's in an email message. Finally make sure you have a security device like a proxy, that knows sites that contain malicious content and blocks those sites. In recent attacks of well known websites, the URL databases of the best proxies had the malicious websites (the URL's embedded into the well-known sites to cause harm) already categorized as malicious and blocked their access by end-users (who were behind the proxy).
Friday, June 13, 2008
SMB Signing and the Proxy
In the world of file sharing, anyone with a Microsoft environment knows that SMB Signing is one way to ensure that the client is talking with the server that its supposed to. SMB Signing guarantees that the there's no device in between the client and the server intercepting the traffic and stealing company secrets or hacking in trying a man-in-the-middle attack.
That's a great philosophy if you know your network is secure and you have no devices in the way that will interfere with the network traffic. The problem of course comes into play when you talk about devices that do interrupt the flow of network traffic. Devices that are designed to terminate network traffic, like the proxy. If you've deployed an in-line proxy, you already know that you have to make exceptions for specific types of traffic and allow that traffic to bypass the proxy. We've talked about some of these different types of traffic in previous articles here, including VoIP. SMB Signing falls into this bucket as well. In order to guarantee you're going to file share you want to go using SMB Signing, you'll need to make sure your proxy can allow traffic for SMB Signing to go through in bypass mode.
Where's the problem in all of this? There are some proxies that will allow you to intercept SMB Signing from the client and let the proxy claim it is the file server, and the re-establish the connection to the file server from the proxy. Essentially, a man-in-the-middle. While this approach may work (meaning the client can successfully connect through and get files), it seems some how wrong as it has broken the essential trust model that SMB signing was based on to begin with. If SMB Signing guarantees you're talking with the file server you're think you are, how does allowing a man-in-the-middle keep that trust? If your proxy can be a man-in-the-middle in SMB Signing, why can't something with malicious intent do the same thing and without your knowledge?
Perhaps it's best to let SMB Signing do what it's supposed to. Guarantee you're talking to the server you think you are. Bypass that traffic on the proxy, and there's no worries if you ever need to audit the connection and figure out what happened to that traffic.
That's a great philosophy if you know your network is secure and you have no devices in the way that will interfere with the network traffic. The problem of course comes into play when you talk about devices that do interrupt the flow of network traffic. Devices that are designed to terminate network traffic, like the proxy. If you've deployed an in-line proxy, you already know that you have to make exceptions for specific types of traffic and allow that traffic to bypass the proxy. We've talked about some of these different types of traffic in previous articles here, including VoIP. SMB Signing falls into this bucket as well. In order to guarantee you're going to file share you want to go using SMB Signing, you'll need to make sure your proxy can allow traffic for SMB Signing to go through in bypass mode.
Where's the problem in all of this? There are some proxies that will allow you to intercept SMB Signing from the client and let the proxy claim it is the file server, and the re-establish the connection to the file server from the proxy. Essentially, a man-in-the-middle. While this approach may work (meaning the client can successfully connect through and get files), it seems some how wrong as it has broken the essential trust model that SMB signing was based on to begin with. If SMB Signing guarantees you're talking with the file server you're think you are, how does allowing a man-in-the-middle keep that trust? If your proxy can be a man-in-the-middle in SMB Signing, why can't something with malicious intent do the same thing and without your knowledge?
Perhaps it's best to let SMB Signing do what it's supposed to. Guarantee you're talking to the server you think you are. Bypass that traffic on the proxy, and there's no worries if you ever need to audit the connection and figure out what happened to that traffic.
Wednesday, June 11, 2008
Internet Speed Bump
As an IT administrator, there's a need to let everyone know what the corporate policy is around web usage. But how do you ensure everyone has seen the corporate policy? The Internet Speed Bump. Your proxy should allow you to create a brief message or a click through to give your end-users a message, whether it be a policy agreement, message of the day, or just an announcment.
This page can be shown for a brief period (5-10 seconds) and then automatically redirect to the requested page, or require a click through for the user to get to their requested page.
Having a speed bump ensures that everyone has read the policy before they go browsing the web.
This page can be shown for a brief period (5-10 seconds) and then automatically redirect to the requested page, or require a click through for the user to get to their requested page.
Having a speed bump ensures that everyone has read the policy before they go browsing the web.
Monday, June 9, 2008
Why Terminate?
I read recently a very rudimentary discussion about what the difference was between a firewall or router and a proxy. The author's very quick and dirty description to explain the difference? Routers and firewalls pass traffic and connections (assuming the policies allow it), while proxies terminate traffic and connections. While this is a simplistic view, it does beg the question, why terminate?
The quick answer? Inspection and security. By terminating the connection, you get to inspect the content of everything going through the box. There's no worry about any hidden content being tunneled through the connection. Proxies have to terminate a connection and rebuild the connection to the final destination.
At the same time proxies are smart enough to know what protocols can't be terminated, and allows certain applications to be bypassed, such as VoIP which would would not be able to tolerate disruption.
Typical routers and firewalls either allow or block traffic. Most organizations allow HTTP (web) traffic through the firewall and router. End-users can go to the web, to even secure (HTTPS) sites, but without a proxy, there's no visibility to what the user is doing, whether they are downloading malware, sending out confidential information (against corporate policy), or visiting sites that are not condoned by human resource regulations.
The proxy provides the visibility and control the IT administrator needs for today's applications.
The quick answer? Inspection and security. By terminating the connection, you get to inspect the content of everything going through the box. There's no worry about any hidden content being tunneled through the connection. Proxies have to terminate a connection and rebuild the connection to the final destination.
At the same time proxies are smart enough to know what protocols can't be terminated, and allows certain applications to be bypassed, such as VoIP which would would not be able to tolerate disruption.
Typical routers and firewalls either allow or block traffic. Most organizations allow HTTP (web) traffic through the firewall and router. End-users can go to the web, to even secure (HTTPS) sites, but without a proxy, there's no visibility to what the user is doing, whether they are downloading malware, sending out confidential information (against corporate policy), or visiting sites that are not condoned by human resource regulations.
The proxy provides the visibility and control the IT administrator needs for today's applications.
Friday, June 6, 2008
Packeteer in a Proxy?
Last month Blue Coat announced intentions to purchase the networking company Packeteer. Today they released an announcement that the deal has been completed. As one of the heavy weight leaders in the proxy market, it led many of us to wonder what is it, that Packeteer can do for a proxy.
For those of you unfamiliar with Packeteer, their main product line is called PacketShaper, a product that classifies data going across the network, and gives the administrator the ability to manage the bandwidth being allocated to different applications. PacketShaper also does some compression and TCP optimization to improve the bandwidth usage of the application.
Blue Coat has called PacketShaper the "crown jewel" they were buying Packeteer for. PacketShaper will definitely give Blue Coat the ability to recognize more applications, and when you recognize more applications, you can probably proxy more applications. In a previous article we talked about proxying applications besides HTTP and HTTPS. With better visibility, you can even start talking about different policies for different HTTP-based applications.
There's no where for the proxy to go, but to get smarter. This is good news for all IT administrators.
For those of you unfamiliar with Packeteer, their main product line is called PacketShaper, a product that classifies data going across the network, and gives the administrator the ability to manage the bandwidth being allocated to different applications. PacketShaper also does some compression and TCP optimization to improve the bandwidth usage of the application.
Blue Coat has called PacketShaper the "crown jewel" they were buying Packeteer for. PacketShaper will definitely give Blue Coat the ability to recognize more applications, and when you recognize more applications, you can probably proxy more applications. In a previous article we talked about proxying applications besides HTTP and HTTPS. With better visibility, you can even start talking about different policies for different HTTP-based applications.
There's no where for the proxy to go, but to get smarter. This is good news for all IT administrators.
Wednesday, June 4, 2008
Developing a Webmail Policy
Does your organization have a policy on who can use external webmail and what can be sent out using external webmail? In today's web world, it's all too easy to get to a web-based email platform and download a malicious virus or to send sensitive corporate data out of a secure private network. With web-based email even more prevalent than client based email today, it's important to set parameters around its use in the corporate environment.
Today's proxies let you create policy around web-based email. It can be an extremely secure policy blocking access to all web-based email, or you can be selective, allowing access to web-based email pages, but prevent downloads of attachment files to prevent any possible download of viruses. Alternatively you can set policy to use an anti-virus scanner to scan any downloads that are permitted by policy.
For outbound DLP (data leakage protection), a proxy can help prevent DLP by sending any outbound documents being sent over web-based email to a DLP scanner via ICAP. We've discussed ICAP as a protocol available to proxies in a previous article in this blog.
With all these options available on many proxies, there's no reason not to have a policy on access to web-based email.
Today's proxies let you create policy around web-based email. It can be an extremely secure policy blocking access to all web-based email, or you can be selective, allowing access to web-based email pages, but prevent downloads of attachment files to prevent any possible download of viruses. Alternatively you can set policy to use an anti-virus scanner to scan any downloads that are permitted by policy.
For outbound DLP (data leakage protection), a proxy can help prevent DLP by sending any outbound documents being sent over web-based email to a DLP scanner via ICAP. We've discussed ICAP as a protocol available to proxies in a previous article in this blog.
With all these options available on many proxies, there's no reason not to have a policy on access to web-based email.
Tuesday, June 3, 2008
Proxy isn't just for the web anymore
When most adminstrators think about proxies, they automatically assume secure web gateways. A proxy to handle web traffic in and out of the corporate network. Today's proxies handle a lot more than just web traffic. Modern proxies can proxy FTP, P2P (peer to peer), IM (Instant Messaging), and other protocols. They also recognize applications within web pages, and many proxies can even filter or block embedded chat mechanisms in web pages.
While proxies provide mechanisms to control these additional protocols they can also set policy for them by user or group. For example, perhaps the sales organization needs IM to keep in touch while they're on the road, so those users can be allowed to chat online, while the remainder of the organization can be forced to use an internal only chat mechanism (like Jabber), or just have it completely restricted. The support organization may need FTP for transferring files for debugging while it's a risk to allow it for the rest of the organization due to DLP (data leakage protection) reasons.
Today's proxies give you a lot more reason to make sure they are part of your network security toolbox.
While proxies provide mechanisms to control these additional protocols they can also set policy for them by user or group. For example, perhaps the sales organization needs IM to keep in touch while they're on the road, so those users can be allowed to chat online, while the remainder of the organization can be forced to use an internal only chat mechanism (like Jabber), or just have it completely restricted. The support organization may need FTP for transferring files for debugging while it's a risk to allow it for the rest of the organization due to DLP (data leakage protection) reasons.
Today's proxies give you a lot more reason to make sure they are part of your network security toolbox.
Subscribe to:
Posts (Atom)
Posts
