ASA: nice-to-know features.

I’ve already made an introduction to the ASA, but when working with them on a regular basis, it’s nice to know some features that come with the product to explain how it reacts and help troubleshooting. So for the interested reader with little ASA experience, below a few features that have proven handy to me.

Full NAT & socket state
Most consumer-grade routers with NAT keep a NAT state table that keeps state only with the source socket . A socket is an IP address and port paired together. For example, the following setup:

When connecting to the web server, remote socket 198.51.100.5:80, a local socket, for example 192.168.1.2:37004 is created. The router will then do a NAT translation to its outside IP address (a NAT/PAT with overloading or hide NAT) to socket 203.0.113.10:37004. This means that if return traffic arrives for destination 203.0.113.10 port 37004, it will be translated to 192.168.1.2 port 37004. However, without stateful firewalling, any packet will be translated back in again on port 37004, regardless of source. This is how some software like torrent programs do NAT hole punching. Also, no matter how big the pool of private IP addresses, the public IP address translations have a maximum of about 64,000 ports available (okay, 65,535 technically but there are probably some reserved and a source port below 1,024 is generally not recommended).

The ASA handles this differently: in combination with the stateful firewall a full state is made for each connection, both source and destination socket. This means the above translation is still done but no return traffic from another source is allowed. On top of that, if another inside host makes a connection towards a different web server, the ASA can reuse that port 37004 for a translation. Return traffic from that different web server will be translated to the other inside host because the ASA keeps a full state. Result: no 64,000 ports per public IP address the device has, but 64,000 per remote public IP address! This allows for even more oversubscription of a single public IP address, assuming not everyone is going to browse the exact same website.

Sequence randomization
A bit further into layer 4: TCP uses sequence numbers to keep track of the right order in a packet flow. The initial sequence number is supposed to be random, but this is not often the case in practice. In fact, one quick Wireshark from a connection to Google gives me this:

The problem is that guessing sequence numbers allows an attacker to intercept a TCP connection or guess an operating system based on the sequence number pattern. That’s where the second nice-to-know ASA feature comes into play: sequence randomization. By adding a random number to each sequence number (the same random number for each packet per flow) it becomes impossible to guess the initial sequence number of the next connection, as well as difficult to do any OS fingerprinting based on it.

Inspect policy-maps
For someone not familiar with the ASA, this is often a point of trouble. By default the ASA has no awareness above layer 4. This means any information not in the UDP or TCP header isn’t checked. Examples are HTTP headers, the FTP port used for transfer (which is in the payload) and ICMP Sequence numbers.

ASA requires configuration of policy-maps for this. This is why by default ping requests through the ASA don’t work: it cannot create a state for it. And for HTTP inspect, it checks for proper HTTP headers as well as the presence of a user-agent header. This means non-HTTP traffic cannot be sent through port 80, and incoming telnets on port 80 towards web servers aren’t accepted either, preventing some scans.

Capturing
Finally, one of the most useful functions. While many other platforms with a Unix-based OS allow some form of tcpdump, Cisco does not support it. However, you can do some form of capturing on an ASA, even with proper filtering.

First configure the ACL that will be used as a filter, otherwise you’ll capture all traffic for that interface.

ASA#configure terminal
ASA(config)#access-list ExampleCapture extended permit ip host 172.16.16.16 any
ASA(config)#exit

Next, find the correct interface name: the ‘nameif’ because the usual interface name will not do.

ASA#show run int vlan16
!
interface Vlan16
nameif Internal
security-level 50
ip address 172.16.16.1 255.255.255.0

Now you can start and show the capture.

ASA#capture TestCap interface Internal access-list ExampleCapture
ASA#show capture TestCap
76 packets captured

1: 16:45:13.991556 802.1Q vlan#16 P0 172.16.16.249.44044 > 203.0.113.10.22: S 3599242286:3599242286(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
2: 16:45:14.035474 802.1Q vlan#16 P0 172.16.16.249.44044 > 203.0.113.10.22: . ack 1303526390 win 17520
3: 16:45:14.037824 802.1Q vlan#16 P0 172.16.16.249.44044 > 203.0.113.10.22: P 3599242287:3599242338(51) ack 1303526390 win 17520
4: 16:45:14.067196 802.1Q vlan#16 P0 172.16.16.249.44044 > 203.0.113.10.22: . ack 1303526754 win 17156
5: 16:45:14.072887 802.1Q vlan#16 P0 172.16.16.249.44044 > 203.0.113.10.22: P 3599242338:3599242898(560) ack 1303526754 win 17156
6: …

Note that traffic is seen in only one direction here. To see return traffic, add the reverse flow to the capture ACL as well. Unfortunately, the capture must stay running while watching the output here. The capture can be stopped as following:

ASA#no capture TestCap

This will erase the capture also, so the show command will no longer work.

Additionally, you can do a real-time by adding the parameter ‘real-time’, but it’s a bit more tricky. This is not recommended for traffic-intensive flows, but ideal to see if a SYN is actually arriving or not.

ASA#capture TestCap interface External access-list ExampleCapture real-time
Warning: using this option with a slow console connection may
result in an excessive amount of non-displayed packets
due to performance limitations.

Use ctrl-c to terminate real-time capture

1: 16:45:51.755454 802.1Q vlan#16 P0 172.16.16.16.43969 > 203.0.113.10.22: . ack 2670019600 win 16220
2: 16:45:51.768698 802.1Q vlan#16 P0 172.16.16.16.43969 > 203.0.113.10.22: . ack 2670019768 win 17520
3: 16:45:51.768774 802.1Q vlan#16 P0 172.16.16.16.43969 > 203.0.113.10.22: . ack 2670019968 win 17320
4: 16:45:51.777501 802.1Q vlan#16 P0 172.16.16.16.43969 > 203.0.113.10.22: . ack 2670020104 win 17184
5: …

Just don’t forget to remove the ACL after you’re done.

Advertisement

Site-to-site VPNs part III: Cisco ASA

Third part of the S2S VPN series. Again with Cisco, but this time on an ASA. Since the ASA can be managed in GUI with ASDM, configuration is quite straightforward.

The S2S VPN configuration menu can be found under ‘Configuration’, ‘Site-to-Site VPN’. There you can add a new VPN connection, or edit an existing one.

The configuration menu needs little explanation, as it nicely covers everything a S2S VPN needs (see part I). Only worth noting is IKEv2, which isn’t used a lot these days and can safely be disabled. The IKE and IPsec proposals are already filled in with all supported combinations. The VPN will work this way but it can be easier to troubleshoot and understand to just allow the proposals that are needed for a VPN.

If you want to use PFS, it can be found under ‘Advanced’, ‘Crypto Map Entry’, together with some more options.

Unfortunately, seeing whether a VPN is up or not in the GUI isn’t possible. But the GUI does have logging, which can show the buildup and even reasons for failure in real-time. The CLI, just like with a Cisco IOS, uses the commands ‘show crypto isakmp sa’ for Phase 1 and ‘show crypto ipsec sa’ for Phase 2. Straightforward, isn’t it?

ASA part II: basic set-up and firewalling.

It’s been a while since I’ve posted anything since I’ve been very busy with lots of personal things.  Until a few days ago, when I needed to set up an ASA urgently as a stateful firewall to protect a web server. The perfect basic setup, but still a challenge for someone inexperienced. So below some brief notes to get an ASA going with basic firewall functionality.

First step: basic configuration of the interfaces. The ASA5505 interfaces work somewhat like a layer 3 switch, with VLAN interfaces and switchports, that can be configured in access, trunk or routed interface mode. Other ASA models work more like a router, with layer 3 interfaces, and subinterfaces for trunk link behavior.
In this example, the first interface on my ASA5505 will become a routed interface for out-of-band access in a 10.0.3.0/24 subnet, the second interface will also be routed and become the external connection with IP 20.30.40.50 (ISP gateway 20.30.40.1), and the remaining interfaces will be switchports part of VLAN 5 with subnet 192.168.3.0/24 as the internal network.

ASA5505#configure terminal
ASA5505(config)#interface Ethernet0/0
ASA5505(config-if)#no switchport
ASA5505(config-if)#ip address 10.0.3.2 255.255.255.0
ASA5505(config-if)#description Management
ASA5505(config-if)#nameif MGMT
ASA5505(config-if)#security-level 100
ASA5505(config-if)#management-only
ASA5505(config-if)#exit
ASA5505(config)#interface Ethernet0/1
ASA5505(config-if)#no switchport
ASA5505(config-if)#ip address 20.30.40.50 255.255.255.0
ASA5505(config-if)#description ISP
ASA5505(config-if)#nameif External
ASA5505(config-if)#security-level 0
ASA5505(config-if)#exit
ASA5505(config)#interface Vlan 5
ASA5505(config-if)#ip address 192.168.3.1 255.255.255.0
ASA5505(config-if)#nameif Internal
ASA5505(config-if)#security-level 50
ASA5505(config-if)#exit
ASA5505(config)#interface range Ethernet0/2 – 7
ASA5505(config-if)#switchport mode access
ASA5505(config-if)#switchport access vlan 5
ASA5505(config-if)#exit

Some explanations here: the ‘nameif’ gives the interface an actual name that can be seen in ASDM and worked with for all firewall rules to come. The security-level is used by the ASA to determine which interface is considered a safe-zone, and which one is not. By default, traffic from safer interfaces (higher security-level) can flow to less secure interfaces, but not the other way around (except for the return packets of stateful connections). Equal security-level interfaces can’t pass traffic between each other by default, but this option can be toggled in the ASDM, or by the ‘same-security-traffic permit inter-interface’ command. Also, the ‘management-only’ command on the management interface prevents that interface from being part of the routing, so no packets from and to any other interface can be passed through this interface.

Next is setting up a local user account for SSH and ASDM access, as well as an enable password. Consider this mandatory for any ASA.

ASA5505(config)#user reggle privilege 15 password ********
ASA5505(config)#enable password ********
ASA5505(config)#aaa authentication ssh console LOCAL
ASA5505(config)#ssh 0.0.0.0 0.0.0.0 MGMT
ASA5505(config)#http server enable
ASA5505(config)#http 0.0.0.0 0.0.0.0 MGMT
ASA5505(config)#asdm image disk0:/asdm-645-206.bin

Again more explanation: the third line makes sure the local username database is used when trying to log in on SSH. RADIUS and TACACS+ are also possible of course, but I’m not going to cover that here. The fourth and sixth line define who may connect to SSH and ASDM, respectively. In this case I allow access from any IP (0.0.0.0/0), but only on the Management interface, which is defined by the nameif configured earlier. You can add multiple lines with multiple subnets and interfaces, but this is a basic example.

The last line is also required or ASDM will not work. It defines where on the local system the ASDM installation file is located. The file has to be present! The version may differ of course and can be downloaded on the Cisco website. The positive side of this is that once all of this is configured, you can connect to the ASA with your browser and it will provide you with a download link for ASDM if you don’t have it installed already. This can save you a lot of searching when you urgently need to log in from a computer that doesn’t have this installed yet. Note that ASDM does require a modern 32-bit Java to function, even on 64-bit operating systems.
The last thing I do in the console after this is setting up basic static routing: a  default route towards the internet on the External interface. The Management interface is a bit trickier and I haven’t worked that one out yet: everything in the local 10.0.3.2 subnet can connect, but I haven’t tested if setting a default route for the Management interface actually works, so I’m not going to define one here.

ASA5505(config)#route External 0.0.0.0 0.0.0.0 20.30.40.1

That’s the end of the console part. For firewalling and NAT, I prefer the ASDM now. Logging in is done by surfing to https://10.0.3.2 and giving the username and password configured earlier. It’s an easy to understand interface. First NAT, which you can find under ‘Configuration’ in the menu above, then ‘Firewall’ on the left, and finally ‘NAT rules’, also on the left. There you can add new rules on the interfaces.

In the NAT rule menu, you can add objects (which you can create there too) that must be translated. For example, a dynamic or hide NAT of the 192.168.3.0/24 network behind the address of the External interface, 20.30.40.50. Static NAT rules for servers are also possible and you can NAT those behind addresses not configured on any interface, for example if you’ve received a range to use from your provider or own an IP range. In the last case, make sure routing (likely BGP for your own IP range) is pointing towards the ASA for the IP’s you’re going to use.

When your changes are done, you can click apply on the bottom of the screen to push the configuration towards the ASA. The ‘Save’ button on top of the screen acts the same as ‘copy run start’.
Next, under ‘Access rules’ on the left you can define the actual firewall rules. Again the same simple interface to add objects in rules, source, destination, ports, time frames,… I’m not going to explain in detail, it’s easy to experiment with should you have the chance to do so. A few points to keep in mind though:

• The rules are examined top-down. So if the first rule denies something, even a dozen allow rules after that will not change the decision.
• Top-down means it takes CPU to match something on the bottom of a long rule list. Luckily, the ASA shows the number of hits on each rule in the ASDM, so you can place the most-used rules on top of the rule list to reduce CPU load.
• When defining an object, use netmask 255.255.255.255 to define a single IP.
• If you’re using NAT on an external interface, don’t define any rule on that interface with the internal IP address of a NAT rule. It will of course not match any incoming packet.
• I’m very fond of how easy the ASDM interface is, but keep in mind this is a GUI which pushes configuration towards a device. This push action can be interrupted, which may result in missing rules or configurations. So for larger configurations, it can’t hurt to push ‘Apply’ twice from time to time.

This configures a basic ASA firewall. Biggest challenge after the configuration: connecting the cables correctly!

ASA part I: introduction.

And yet again I got the chance to test a device at home. This time: a Cisco ASA5505. ASA stands for Adaptive Security Appliance, and this branch of devices specializes in security features, such as NAT, stateful firewalling, IPS, and VPN. It supports site-to-site VPN, client-based VPN, SSL VPN,… Strangely enough, no support for DMVPN yet. The full product list can be seen here.

The ASA5505 is the smallest in the series, and the only one which does not come as a rack-mountable unit. It does have almost the same functionality as the other models: difference between models is in throughput, processing power and number of concurrent VPN sessions mostly. Port count starts with 0, and ports 6 and 7 support PoE.

The lower models ASA’s (5505 and 5510) come with a differentiated licences model, which can be checked here. Basically, the license costs more depending on the number of users, where users means the number of IP’s or devices. The one I’m testing has a Security Plus license, which is the highest for the model, with unlimited users and full functionality. Keep in mind that not everything I’m going to explain in the upcoming series of ASA posts may work on a lower license.

An ASA handles quite differently compared to a standard Cisco IOS. ASA runs a custom Linux/Unix version as operating software (so do the Cisco Nexus series), and commands differ. ‘show ip route’ is ‘show route’, ‘show ip interfaces brief’ is ‘show ip’, for example. Also, you can connect Adaptive Security Device Manager, or ASDM, to it to configure the ASA in a GUI. Given the complex possibilities of the device, this is quite handy, although the (Java-based) ASDM tool does contain a few minor bugs and in some configurations creates extra rules in the background, that can be seen from the command-line, but not in the ASDM.

For firewalling, it allows a lot of options with a modern software release: rules are defined with objects. Those objects can be source addresses or networks, destination addresses or networks, destination ports or port groups (both UDP and TCP), and time frames. All these rules can be defined in both IPv4 and IPv6. They also show the number of hits, so you can see which rules are used and which ones aren’t. Optionally you can use this feature to move the most-used rules to the top to reduce CPU load (rules are examined in the order they are listed).

In upcoming blog posts, I’m going to describe basic ASA functions, so stay tuned!