Monday, January 26, 2015

Security101 : What is a firewall?

Security101 is a series of short, direct, no fluff articles about security basics.  To see the entire series, click here.

What is a firewall?  A firewall is a security device whose main purpose is to allow or deny data into or out of a network based on a set of configured rules.

Typically firewall rules use a combination of source IP, destination IP, source MAC, destination MAC, TCP port, UDP port, and protocol to determine if traffic is allowed.  Within traditional firewalls (as opposed to Next Generation Firewalls) once a traffic stream has been allowed based on a rule, there is no further inspection of that traffic stream.

Basic Firewall Example
Additionally, in stateful firewalls (which most modern day firewalls are) response traffic back thru the firewall is not inspected.  For example, if a PC requests a web page from a web server the firewall protecting that web server will allow the traffic into the web server if it comes into the expected port, port 80 or 443 in most cases.  This initial request begins a "conversation".  When the web server responds to the PC's request the firewall checks its conversation table to see if it saw the beginning of this conversation.  Since the answer is yes it allows the response from the web server to the PC without any further inspection.

Firewalls do not look any deeper than source, destination, port, and protocol to determine if traffic is allowed or not.

Firewalls can be used to control traffic into or out of any network at any place in your LAN or WAN.  Firewalls are most often put at the internet edge and are often seen controlling traffic into and out of the data-center or segmenting the desktop networks from the rest of the LAN.

Wednesday, August 20, 2014

DHCP or Static IP Addresses?

So you are setting up a new network, say a small network to support manufacturing automation equipment like a SCADA over IP network.  It doesn't have to be this. It could just be a new office, or a remote site, or even a lab environment in your home.  No matter the circumstance you have a number of devices that need to keep the same IP address forever.  The question is, " to Static, or not to Static"?

Your initial instinct might be to go with static.  And I wouldn't blame you.  After all, it is a small network.  You'll likely have very little change. In the example its a network that won't have devices that frequently join and leave and they're not end-user devices.  Static is a natural.  Or is it?

While static is simple to setup and very dependable, it doesn't give you anything other than address assignment.  It would be like assigning a locker to every kid that enrolled at a high school and keeping track of it in a spiral bound notebook.  Yes, it works, but there will be students who leave and nobody tells you.  There will be students who enroll but are never assigned a locker because somebody dropped the ball.  Eventually the oversights and mistakes will cause you to run out of lockers. And then what will you do?  Do you really want to review a list of each of the 4,000 students who have attended for the last 4 years against the list of 1,200 lockers in the school?  Shoot me now.
How many lockers are there in a typical high school any way?  And how would you plan for that?  Probably the same way you plan your IP network.  How many students will I have when the school opens?  What is the total capacity of the school?  How many extra should I buy to accommodate the undoubted overcrowding that will happen eventually? 

How many devices do I need addresses for immediately?  What is the maximum devices I expect for this network?  When management won't buy new hardware and I have to squeeze even more devices in, how many can I possibly support before failure occurs?  Hopefully you don't work in that environment, and between CIDR and supernetting you can be pretty flexible, but you still need to plan.  Even if you only use a class C /24 network, you'll have 254 addresses to keep track of (yes, I know, you could subnet into a smaller network).

DHCP, even for a network of 5 devices, is a better option.  At least, when you use DHCP reservations.  A DHCP reservation links a MAC address with an assigned IP address.  A simplified process goes something like this:
  1. Device or PC sends a DHCP request out onto the network.
  2. DHCP server (can be a firewall, router, Layer 3 switch, or actual DHCP server) sees the request and checks the device's MAC address against 2 tables.  It checks both the assigned addresses (devices that have already received a random IP address) and it checks the DHCP reservation table.  The reservation table lists IP addresses that are permanently assigned to specific MAC addresses.  If either match it responds with the appropriate address. If not, it assigns a random address from the appropriate pool.
  3. The device or PC receives the address and begins using it.
And what do you get with DHCP reservations?  You get tracking.  Logging.  Intelligent address assignment.  Dynamic changes (like if the gateway or subnet mask needs to change to accommodate growth, or if the DNS server changes, or if the time server changes, etc.).  You know the last time an address was used.  You can see when unknown devices using DHCP join the network.  You get flexibility.  You get...control. 

Without DHCP, using static addresses, you get...a black hole. 

Even for a small network, DHCP is your friend.  It takes little time to set up, but if you don't I can promise that at some point you will wish you knew some detail about the network or you'll need to make a mass networking change to all devices and can't.  And that means you'll be walking from one device to the next manually making the change.  Enjoy your day!

If you still decide to go with static, let me just say now something that will certainly apply later,  "I told you so".

WCCP on Cisco ASA

I found myself in a situation a couple weeks ago where a customer wanted to inspect traffic destined for the internet for certain types of data (i.e. credit card numbers, SSNs, birth dates).  They had invested in a Cisco WSA (Web Security Appliance, formerly Ironport) and only wanted call center traffic inspected.  To do this, I needed to redirect select "interesting" traffic as it traversed the ASA thru the WSA prior to passing it out to the internet.  The diagram below may help to illustrate.

Using WCCP we are able to redirect the "interesting" traffic from the ASA to the WSA to be reviewed.  Below are the ASA commands and steps necessary to make this happen.

1. Create an access-list to identify the interesting traffic:
access-list Redirect_List line 1 extended permit ip any

2. Create an access-list to identify the WSA server that the traffic will be sent to:
access-list Group_List line 1 extended permit ip host any

3. Create the policy that will control the redirection of traffic:
wccp web-cache redirect-list Redirect_List group-list Group_List

4. Apply the policy to the desired interface. In this case it will inspect and act on traffic coming into the Inside interface.:

wccp interface inside web-cache redirect in 

That is all it takes. Identify what you want to redirect,  identify where you want it sent,  create the rule, apply the rule.  Obviously there are other considerations both on the LAN and in the WSA that need to be addressed, but from the firewall's point of view this is all there is.

If you're interested in the configuration guide for the ASA 9.0 CLI, you can find it HERE

Tuesday, July 8, 2014

ASA Sub-Interfaces

Question From A Customer

Question: I have an ASA in production with several ports configured.  One of these ports has a single IP assigned to it, and an ACL applied to it.  If I create sub-interfaces under that port and trunk into it with various VLANs from the upstream switch, what will happen to the "main port's" configuration?  Will it still work too?

Answer: Keep in mind that you create an ACL and then “apply” it to an interface.  As soon as you create virtual sub-interfaces under a physical interface, from a software and config perspective that physical interface goes “dormant” and virtually all its configuration(s) other than speed and duplex are ignored.  As a result, any ACL applied to that main interface will no longer affect traffic that physically traverses the port.  So in short, your current ACL will stop working (and it will look like the port did too).

Most likely as soon as you configure a sub-interface on the port it will stop passing traffic or applying rules.  My recommendation is that if you have a free port on the FW, configure that with all your changes, sub-intefaces, VLANs, etc, while it is in a down state and then when ready bring it up and physically move the cable.  If you don’t have a free port and are only using the base ports included with the chassis, you may want to look at adding the 4/6 port expansion card (depending on model).

There can be other unforeseen effects as well, and running an Active/Active or Active/Standby cluster may complicate it further, so if you feel the least bit uncomfortable with this change, or if you work for a company with a low tolerance for "learning on the job" or has very short maintenance window it may be a good idea to get a qualified engineer on the line (or onsite) to help with the prep work and/or cut-over.  They can help you pre-build the configs, check at the upstream and downstream switches to make sure there won’t be issues, and then be available during cut-over to get any problems corrected quickly.

If you don't have a trusted network company you already work with, reach out to me and I'll put you in touch with a qualified engineer.  Contact info is on the right side of the page under "Professional Inquiries".

Friday, June 20, 2014

Licensing Cisco ASA 5500-X NGFW (CX) for Redundancy

If you are working on budgets and are considering replacing your firewall, you may run into this question, and the answer is not particularly easy to find.  "If I buy a pair of ASA 5500-X firewalls and plan to run them active/active, and  want to run the Next Generation Firewall (NGFW) (formerly CX) feature set, do I need one subscription license for the pair or do I need one for each chassis?".

Based on the Partner Ordering Guide (requires CCO login and partner status), updated Dec. 2013,  in version 9.2.1 of the ASA code you need one subscription license per physical chassis.  A screen shot of the line is below for those who can't get the original doc.

The logic behind this doesn't make a whole lot of sense, and I expect they'll change it at some point.  On the surface it seems logical, two chassis can each pass traffic and so should each be licensed.  If Active/Active were an option for NGFW I would agree, however, at this point the NGFW only supports Active/Passive which means that only one chassis at a time will be passing traffic and when a fail-over does occur, the passive device (now active) will continue to pass NGFW traffic without inspection if it is already midstream.  So to summarize:

1. You have to have a subscription license for each chassis, despite the fact that logically they are one.
2. You have to have a subscription license for each chassis, despite the fact that you can't run the NGFW features in active/active mode (the traditional firewall features still support this, just not AVC, WSE, or IPS)
3. You have to have a subscription license for each chassis, despite the fact that the NGFW doesn't share session state between chassis (the traditional firewall features still support this, just not AVC, WSE, or IPS) so fail-over don't allow uninspected traffic.

Give the demand for A/A firewalls, I'm certain in the near future they'll release a version of the NGFW code that supports passing state information between firewalls as well as allows for Active/Active deployments.  They'll also likely build support for a single subscription for Active/Passive pairs.  However, right now we'll have to continue to pay for it like it supports A/A and hope at some point it becomes reality.

Friday, June 6, 2014

vCloud Hybrid Service (In the middle of the night)

My wife shook me awake at 3am this morning.  She asked me, "what is vCloud Hybrid Service?".  I blinked at her several times trying to figure out if I was dreaming and wondering why she would even be curious about that.  As I came fully awake I could hear a man's voice in our house.  He was saying, "with the vCloud Hybrid Service you can setup virtual data centers...".  I wasn't dreaming; the training video I had been watching before bed had somehow restarted and was blasting thru the house at full volume.  As I stumbled downstairs to turn it off I wondered to myself "how did this happen, and exactly how many virtual data centers can you have??".  Well, at least it didn't wake the kids.

Thursday, May 29, 2014

Configuring the Cisco IOS to Log Login Attempts

This post is part of a larger project on getting your devices to email you a list of daily config changes.  It is titled, Keeping Track Of Cisco IOS Device Config Changes.

How many times in a month does someone try to log into your switches or routers?  And who is it? Do you care?  You should, and it isn't that hard to find out and keep track of. With two lines you can configure your switch or router to track what IP Address they came from and what time of day they attempted to log in.  It isn't much, a username would be great too, but it is something to go on.  The commands you want to enter are:

login on-failure log
login on-success log

Once you have entered these two commands and saved the config, you will begin to see entries in your logs that look similar to this:

*Mar 21 20:57:01: %SEC_LOGIN-5-LOGIN_SUCCESS: Login Success [user: test_user] [Source:] [localport: 22] at 16:59:53 CDT Wed Mar 21 2012