I've been following Palo Alto as a networking company for a couple of years now. Their claim is that the days of the port-based firewall are dead and that their application-centric approach is a far better way to enforce your access controls. Take the HTTP protocol for example. HTTP typically runs as a service on port 80, but does that mean that everything running on port 80 is HTTP? As an attacker looking for a way to funnel data out of your organization, why not use the standard HTTP port to send data, since I know you leave it wide open in order for your employees to surf the web. There's nothing to say that I actually have to be running an HTTP server on the other end and there's nothing on my classic firewall to tell any differently. At first, I was admittedly a bit skeptical. I didn't think that you could really tell enough about different applications on the web to be able to separate them out like Palo Alto claims to. Fortunately, Palo Alto reached out to me and provided me with a brand new PA-200 in an attempt to change my mind.
When the PA-200 arrived, it came with everything that I would need to get it up and running. That includes the unit itself, a power supply, a D89 to RJ45 console cable, an ethernet cable, and some instructions and warranty information.
On the front of the unit is four ethernet ports for your devices, a management port, a USB port, a console port, and several status indicator LEDs.
By default, the appliance is configured with ethernet ports 1 and 2 paired as a WAN to LAN link as this is the configuration that the majority of the people who buy it will likely use it for. That said, by following the instructions to connect your computer up to the management port, you can quickly access the user interface that allows you to change this assignment.
This shows the ethernet 1 and 2 interfaces as both being a "virtual wire" and here we can see the virtual wire that connects the two.
From here, we can take a look at the "zones" and see that our two interfaces have been defined as an untrusted (ethernet 1) and trusted (ethernet 2) zone.
To think of this a different way, my cable modem WAN connection (ie. the Internet) goes in my "untrust" zone and my local network (ie. LAN) goes in my "trust" zone. Now all that's left is to set our policy and for ease of management to start with, I set it to allow everything out with a default deny all inbound.
With this configuration I had done enough to be up and running on the device and I immediately started to see data populate the dashboard on the top applications running on my network.
It's color coded based on risk level and the dashboard also provides me a similar view of Top High Risk Applications. Any of these boxes can be clicked on in order to provide additional data about the protocol, sources, destinations, countries, and more.
Now, let me say that while I'm running this on my home internet connection, this thing is a hoss and can do way more than I can throw at it. With their App-ID technology enabled you can throw 100 Mbps of throughput at it no problem. In addition to being an application firewall, it also does standard port-based firewalling, VPN, routing, switching, and so much more. It's so extremely versatile that this thing could easily be placed in a smaller branch office and replace multiple other devices on their network such as a firewall, router, and VPN concentrator. More functionality for less money...who wouldn't want that? In addition to these default capabilities, additional licensing can also be obtained to allow you to do URL filtering, malware detection, and more. Having just gotten this up and running, I'm still exploring the ins and outs of all of the functionality, but it's pretty exciting to have all of this capability in a box that is smaller than the cable modem my ISP provides me. More posts to come on this as I get deeper into the guts of running my new Palo Alto PA-200 !
I was talking with my coworkers this afternoon about Time Warner's plans to jack up rates for high-bandwith users and it got me thinking about how much of their precious bandwith I am actually using. I know that my router at home has a web browser interface where I can get that information, but I have it intentionally only allowing access from the local area network interfaces. I needed to find another way to view the site from work while making the router think that I was on the right network. What I ended up doing was using PuTTY to create a SSH tunnel from my work computer to my Linux box on the home network. I then just pointed my browser at the forwarded port on my work computer and up comes my router's web interface. Who needs VPN when you have PuTTY? Anyway, here are the exact steps that I took to do this:
- Start PuTTY
- Under Connection->SSH->Tunnels specify a source port (the localhost port you want to connect to) and a destination (IP:port) that you want to connect to on your home network.
- Source port: 8008
- Destination: 192.168.0.1:80 (or whatever IP your router is at and it's web interface port)
- Click "Add"
- Under "Session" specify the host name for your SSH server that lives on your internal network, but is exposed via port forwarding on your router with port 22.
- Click "Open"
- When prompted, enter your username and password for your SSH server.
- Now just pull up your favorite web browser and navigate to http://localhost:8008. You should see the page just like you would if you were sitting at home.
As I'm preparing to take my trip to New York for the OWASP AppSec Conference, I came across a timely article on the risks involved with using a hotel network. The Center for Hospitality Research at Cornell University surveyed 147 hotels and then conducted on-site vulnerability testing at 50 of those hotels. Approximately 20% of those hotels still run basic ethernet hub-type networks and almost 93% offer wireless. Only six of the 39 hotels that had WiFi networks were using encryption (see my blog on why are people still using WEP for why this is necessary). What does this mean for you, Joe User? It means that both your personal and company information is at risk any time you connect to those networks. The next time you're surfing the web, start paying attention to all of the non-SSL links (http:// versus https://) that you visit. Then, think about the information that you are passing along to those sites. Are you signing in with a user name and password? Entering credit card information? Whatever it is, you better make sure that it's something that you wouldn't feel bad if it wound up on a billboard in Times Square, because that's about how risky your trasmission could be.
Before you get too concerned, there are a few things you can do to try to prevent this. First, DO NOT visit any links where you transmit information unencrypted. This is just asking for trouble. Since many man-in-the-middle type attacks can still be used to exploit this, my second suggestion is to use some sort of VPN tunnel. Whether it's a corporate VPN or just a freebie software VPN to your network back home, this allows you to encrypt all traffic over the untrusted hotel network. Make this your standard operating procedure anytime you connect to an untrusted network (not just a hotel) and you should keep your data much safer. Lastly, please be sure to have current firewall and anti-virus software on the computer you are using to connect to the untrusted network. The last thing you want is to get infected by some worm or virus just by plugging in to the network.
One other thing that I think that deserves mentioning here is that if you don't absolutely have to use the internet on an untrusted network, then don't do it. Obviously, there are times when you need access to do work, pay bills, etc, but if you can save those tasks until you reach a more familiar (and hopefully safer) network, that is far and away the best way to keep yourself and your data safe.