Quick overview of IPSEC and SSL VPN technologies

Quick overview of IPSEC and SSL VPN technologies

Introduction

This document is regarding the quick look out of two VPN technologies. It covers the difference and strengths of both technologies.

IPSEC:

-      It works on Layer 3 (Network Layer) of OSI Model.

-      Since, it works on Network Layer; it secures all data that travels between two end points without an association to any specific application.

-      Once, it gets connected then the person will be virtually connected to the respective entire network and able to access the entire network

-      It defines how to provide data integrity, authenticity and confidentiality over insecure network

like Internet.

-      It completes its goal through tunneling, Encryption and Authentication.

-      It is complex because the two entities which will communicate via IPSEC have to agree on same security policies which must be  configured on the both end of the devices.

-      A Single IPsec tunnel secures all the communication between the devices regardless of traffic type. It can be TCP, UDP, ICMP etc. or any application like e-mail, client-server, and database.

-      Special purpose software is available for IPsec connections. This can be for PCs, Mobiles, and

PDAs as well as for edge devices like Routers and Firewall.

SSL VPN:

-      It works on Layer 7 (Application Layer) of OSI Model.

-      It is a protocol used for secure web-based communication over the Internet.

-      It uses encryption and authentication to keep communications privatebetween two devices, typically, web server and user machine.

-      Like IPsec, SSL also provides flexibility by providing level of security.

-      Unlike IPSec, SSL helps tosecure one application at a time and eachapplication is supported via web browser.

-      All basic web browser application such as IE or Mozilla supports SSL, by default. But, not all the application supports same so it requires upgrading which is very cost consuming.

-      Above problem can be resolved by purchasing SSL VPN gateway which is deployed at the edge

of the corporate network and serve as a proxy to LAN application such as e-mail, file servers and the other resources.

-      The browser thinks it is directlycommunicating with the application and applicationthinks it is directly communicating with browser.SSL VPN makes it transparent to the either side of the network.

SSL VPN delivers the following three modes of SSL VPNaccess:

•      Clientless—Clientless mode provides secure access to private webresources and will provide accessto web content.This mode is useful for accessing most content that you would expect to access in a web browser, such as Internet access, databases, and online tools that employ a web interface.

•      Thin Client (port-forwarding Java applet)—Thin client mode extends the capability of the cryptographic functions of the webbrowser to enable remote access to TCP-basedapplications such as Post Office Protocol version 3 (POP3), Simple Mail Transfer Protocol (SMTP), Internet Message Accessprotocol (IMAP), Telnet, and Secure Shell (SSH).

•      Tunnel Mode—full tunnel client mode offers extensive application support through its dynamically downloaded Cisco Any Connect VPN Client (next-generation SSL VPN Client) for SSL VPN.Full tunnel client mode delivers a lightweight, centrally configured and easy-to-support SSL VPNtunneling client that provides network layer access to virtually any application.

Strength and Weaknesses:

IPsec‘s key strength lies in its ability to provide a permanent connectionbetween locations. Working at the network layer (layer 3 of the network stack) also makes it application agnostic: Any IP-basedprotocol could be tunneled through it. This makes IPsec an attractive alternative to an expensive leased line or a dedicatedcircuit. It could also serve as a backup link in the event that the primary leased line or dedicated circuitconnectingthe remote site to the central office goes down.

IPsec's application-agnostic designis also its weakness, however.Thoughit provides authentication, authorization and encryption, while basically extending the corporate network to any remote user, it does not have the ability to restrict access to resources at a granular level. Once a tunnel is set up, remote users can typically access any corporate resource as if they were pluggeddirectly into the corporate network. These VPN security concern are exacerbated because having a mobile workforce requires allowing non-managed IT assets like smartphones and home PCs to access corporate resources.These are assets that IT has novisibility into or control over, andthere is no guarantee that these

Devices comply with the level of security that is typically enforced on managed assets.

IPsec is also more involved to maintain. In addition to setting up the appliance to terminate the tunnels, additional configurationand maintenance are requiredto support the remote user population. In situations where corporations use Network Address Translation (NAT), special configuration is required to ensure IPsec plays nicely with the NAT setup.

SSL VPNs, on the other hand, have been designed from the ground up to support remote access. They do not require any special software to be installed. Remote access is provided through a browser-based session using SSL.SSL VPNs also provide an enterprise with the ability to control access at a granular level. Specific authentication and authorization schemes for access to an application can be limited to as particular user population. Built-in logging and auditing capabilities address various compliance requirements. SSL VPNs also have the ability to run host compliance checks on the remote assetsconnecting to the enterprise to validate they are configured withthe appropriate security software and have the latest patches installed.

This does not meanSSL VPNs are the panacea to all of IPsec’s weaknesses. If a remote site requires analways-onlink to the main office, SSL VPN would not be the solution. IPsec, being application agnostic, can support a number of legacy protocols andtraditional client/server applications with minimal effort.This is not the case withSSL VPNs, which have been built aroundWeb-basedapplications. Many SSLVPNs getaround this weakness by installing a Java or ActiveX-based agent on the remote asset. This installation is typically achieved seamlessly after the remote asset has successfully authenticated tothe SSL VPN appliance, though it should be noted that both ActiveX and Java come withtheir own security weaknesses that attackers commonly seek to exploit.

IPSEC or SSL VPN:

Each VPN method has its place in an enterprise. Ideally, as SSL and IPsec VPNs serve different purposes and complement each other, they should both be implemented. IPsec should be leveragedin situations where an always-on connection toremote office locations or partners/vendors is required. In these instances, granular access control limitations and missing host-check capabilities should be augmented with aNetwork Access Control (NAC) system, whichcan ensure only approved remote hosts are allowed to connect to the enterprise. Enterprises shouldleverage SSL VPNs primarily as a remote access method for the mobile workforce where granular access control capabilities, auditing and logging, and security policy enforcement are crucial. But, regardless of your VPNchoice or specific needs, remember that a VPN must notonly be updated, tested and monitored for performance, but also employedas part of a defense-in-depthstrategy that utilizes comprehensive policies and a variety of network security technologies.

Related Information

SSl VPN

IPSEC VPN

Logging options on the Cisco ASA

Logging options on the Cisco ASA

Introduction

Logging is a critical function of any device in your network, but perhaps even more so on a firewall. Whether you are troubleshooting an issue, following an audit trail or just wanting to know what is going on at any time, being able to view generated logs is highly valuable. This post looks at logging options on the Cisco ASA and discusses some of the things you need to consider.

Tick clock

It’s all very well looking through your logs as individual events but if you want to tie them together, particularly across multiple devices, then you need to ensure that all of your devices have the correct time configured. Nothing says ‘I love you’ more than a time stamp that you can trust. If you use a centralized logging solution, you can filter logs across multiple devices to help determine root cause of issues. You can configure time on the ASA manually by using the following commands:

1 2 3

ASA#clock set 12:23:00 JUN 02 2015 ASA#clock timezone GMT 0 3 ASA#clock summer-time BST recurring last Mon jun 2:00 last Sun Oct 2:00

The above lines configure the time, the time zone relative to UTC and the daylight savings time settings respectively. There is a battery on the motherboard of the ASA that will keep the time should the device lose power or be rebooted. However, locally configured time can drift over…time, so what we really want is to use a trusted external time source that all devices synchronize against and this is where NTP comes in.

1 2 3 4

ASA(config)#ntp authenticate ASA(config)#ntp authentication-key 1 md5 fred ASA(config)#ntp trusted-key 1 ASA(config)#ntp server 192.168.1.11 key 1 source inside prefer

Lines 1-2 above dictate that we should be using authentication with NTP for added security and gives a key to use. Line 3 is required to advise the ASA that this key is trusted. Line 4 tells us which server to use, which interface it can be found on and which authentication key to use. It also tells the ASA to prefer this time source over other NTP servers of the same judged accuracy based on what stratum they are in. You should configure at least two NTP servers for redundancy. In the event that all servers are unavailable for an extended period, the ASA can fall back to using the local clock. NTP is a Jekyll and Hyde protocol. It can be as simple to understand as the last section or you can dive deep in to its bowels and be lost forever.

Log destination

Logs can be sent to several destinations but before I list them, it should be noted that logs come from two key sources, system events and network events. System events include things like CPU errors, network events include packets being denied on a certain interface. Both types of messages are dealt with by the logging subsystem and are then potentially filtered prior to being sent to one of the following destinations:

§  Console – logs sent here can be viewed in real time when you are connected to the serial port. As this causes CPU interrupts for each message, you need to be careful when enabling this

§  ASDM – logs can be viewed in the ASDM GUI. From here, you can quickly build filters, colour code the logs by severity and save the log as a local text file to be dealt with later or simply archived

§  Monitor – logs to a Telnet or SSH session. But you don’t still use Telnet for management do you?!?

§  Buffered – this is the internal memory buffer

§  Host – a remote syslog server

§  SNMP – rather than sending logs remotely using the syslog syntax, you can use SNMP to send a trap

§  Mail – send generated logs via SMTP

§  Flow-export-syslog’s – send event messages via Net Flow v9

Log severity levels

Before I show some examples of how to configure different logging, it’s worth looking at the different severity levels available to us. There are eight in total as per Cisco’s definitions below:

Numeric level	Name	Definition
0	Emergencies	Extremely critical “system unusable” messages
1	Alerts	Messages that require immediate administrator action
2	Critical	A critical condition
3	Errors	An error message (also the level of many access list deny messages)
4	Warnings	A warning message (also the level of many other access list deny messages)
5	Notifications	A normal but significant condition (such as an interface coming online)
6	Informational	An informational message (such as a session being created or torn down)
7	Debugging	A debug message or detailed accounting message

By selecting a lower severity (with a higher number), you are also opting in to everything with a higher severity e.g. level 4 will not only log all warnings but all errors, critical, alert and emergency logs. Be wary of selecting too low a severity level, particularly on the console. You can quickly bring a device to its knees if it’s getting hammered.

Examples

Here are some examples to show how to get things up and running.

1 2 3 4 5 6 7 8

ASA(config)#logging enable ASA(config)#logging timestamp ASA(config)#logging buffer-size 128000 ASA(config)#logging buffered warnings ASA(config)#logging monitor 4 ASA(config)#logging trap informational ASA(config)#logging host inside 192.168.1.55 ASA(config)#logging device-id hostname

Line 1 enables logging globally. We then enable timestamps on the log messages, without which it’s difficult to tell when an event occurred. Line 3 configures the size of the local buffer memory. Once this fills up, it is overwritten in a circular fashion. Lines 4 and 5 configure the buffered and monitor destinations previously discussed for the same level, the first using the keyword ‘warnings’ and the second using the equivalent numerical value. Both are interchangeable but will show in various command outputs using the keyword regardless (expect in the logs themselves, where the numerical form will display). Lines 6 and 7 are configured together for remote syslog logging. Line 6 enables the logging at the specified level (in this case informational) and line 7 configures the syslog server IP address and the interface it can be found on.

Line 8 allows various other attributes to be included in each log message. In this case, it will include the hostname but can also include the firewall IP address of a particular interface, the context name (where used) or a specific string. The latter could be useful for using regular expressions for refining logs at a more granular level.

Finally, the show logging command will firstly show the different settings for each logging destination and then the current contents of the local log buffer. Below is an example of its output with just the first log entry for brevity (please note the enabled settings below are not by any means ideal for a production environment, you need to consider what is best for yours):

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

ASA#show logging Syslog logging: enabled  Facility: 20  Timestamp logging: enabled  Standby logging: disabled  Debug-trace logging: disabled  Console logging: level debugging, 204220845 messages logged  Monitor logging: level debugging, 204220844 messages logged  Buffer logging: level debugging, 204220845 messages logged  Trap logging: level debugging, facility 20, 204220844 messages logged   Logging to management 172.16.221.101 errors: 27 dropped: 450   Logging to management 172.16.221.204  History logging: level debugging, 204220844 messages logged  Device ID: disabled  Mail logging: disabled  ASDM logging: level informational, 161093061 messages logged Feb 19 2013 21:41:18: %ASA-4-106023: Deny icmp src outside:10.0.0.1 dst inside:172.16.46.252 (type 3, code 1) by access-group "OUT_IN" [0x0, 0x0]

One thing to note about logging to Telnet\SSH sessions using the monitor destination. Whilst you may have this enabled and will be able to see the messages logged count in the above output rising each time, you may find yourself confused as to why, whilst SSH’d on to your ASA, you aren’t seeing the logs on your screen. To view logs for the current session, assuming they are enabled, you need to type this command in whilst connected:

1	ASA#terminal monitor

and the logs will start appearing according to the severity level you have set. In a move that I can only attribute to Cisco allowing a drunken intern to come up with the command to negate the above one, somebody settled on:

1	ASA#terminal no monitor

Thanks drunken intern guy. To finish off this post, I’ll bundle some other commands together with a brief description:

1 2 3

ASA(config)#logging standby ASA(config)#logging debug-trace ASA(config)#logging emblem

If you have a pair of firewalls configured in a failover configuration, you can enter the first command to enable logging on the standby unit also. Just be aware of the increase in traffic if logging externally to the ASA. The second line will additionally send debug messages to any configured syslog servers, which is disabled by default. Again, this can cause a severe increase in traffic, especially if you enable lots of debugs. The last command changes messages to a proprietary Cisco format and to be honest, I don’t think its used much at all.

Summary

Hopefully you will have learnt a couple of extra things you can do with logging from this post but you can dive even deeper and I suggest you do to get the most out of this critical function. For example, you can archive buffered logs to the local flash or to a remote FTP server, you can disable certain messages completely or just filter them from certain destinations. You can also change the default severity of individual messages to better suit your environment. It would require a certain amount of initial work but would be easily repeatable across your estate.

A great place to learn more is to use the ASDM console which, despite me being a CLI fiend on the ASA, comes in to its own when configuring and reviewing logs. Also pay special attention to what level of logging you have for each destination. I’ve only covered a couple of key points on how best to do this (e.g. disable console logging) as what works best depends on your environment. If possible though, try to use a centralised Syslog server and use the ASDM logging due to it’s immediate nature and filtering capabilities.

Thanks

Mirza Mukaram Baig