Wednesday 26 July 2017

Cisco ASA some hardening commands

Software
Upgrade to the latest recommended release for ASA/ASDM/anyconnect software.
The latest recommended release is likely to be more stable
The very latest release will have the latest bug/security fixes but might contain unknown bugs. 
Its a call you'll have to make which to use latest or latest recommended. Most people take the cautious approach and use latest recommended.
https://www.cisco.com/c/en/us/td/docs/security/asa/compatibility/asamatrx.html#id_65776

ASDM
Some would recommend to disable ASDM as it provides a larger attack surface. However, it is also very useful for day-to-day operation, troubleshooting and management so you will need to make a judgement call/business decision on that. Staff my not have the skills to administer via CLI only. Somethings are just much easier to do in ASDM like certs and anyconnect config. You can move it to a port like 8080 but it won't provide any security benefit.

SSH

If you are using ssh key-exchange group dh-group14-sha1 you may get a warning "the first key-exchange algorithm supported by the server is". Change this to
ssh key-exchange group dh-group14-sha256
You may need to upgrade the sofware on your ASA to get the latest ciphers

Lock down your SSH access only allow it from certain IP's or networks on the INSIDE/OUTSIDE.
ssh 200.30.40.1 255.255.255.255 OUTSIDE
ssh 192.168.100.10 255.255.255.255 INSIDE
The most cautious approach would be to not allow SSH from outside/internet but again this is a decision to be made. I would allowed it but lock to only trusted IPs.

Authentication
You should try to move away from local accounts with passwords that don't change. If you must use local accounts then make sure you use type 9 (at time of writing stronger encryption). You will need to keep local accounts for emergency situations but they should not be used for day to day operations. Ideally we would get an alert if someone logged in with a local account.

Consider radius so windows/network username and password is used to login. Requires setup and config of NPS or radius server in your windows environment. User passwords can be set to a PW policy and set to expire etc. Access can be controlled with AD groups etc.

The best thing to use is 2FA like Cisco Duo. Duo makes setting up 2FA easier than most vendors like RSA. Also requires Duo server/config/setup. Duo is free for up to 7 users then there is a cost. With this setup when you login you also get a prompt on your phone to confirm its you. If a hacker managers to get a password they still can't login as they can't complete the 2FA as you have your phone.

I do usually recommend to leave the console authentication access as local. So remote SSH connections are using radius/2FA but console connections at the physical firewall will use local username and password. This is in case of a network down emergency where you need to get in. You can secure access to your console port by choosing a secure datacentre or if in your own office locked server room with keypad/fob lock and CCTV etc.

Telnet
Telnet should be disabled and not used its not secure (sends password in plain text)
no telnet 192.168.1.0 255.255.255.0 inside

Disable aggressive mode VPNs (PSK is transferred in plain text)
crypto ikev1 am-disable

SSL/TLS
SSL and TLS both get called SSL as a general term.
TLS has replaced SSL.
SSLv2 and SSLv3 are old/defunct (TLS1.0 and TLS1.1 also gone now)
Latest version of TLS (at time of writing) is v1.2 and you should be using this everywhere. If possible.
Anyconnect 3.x doesn't support tlsv1.2, only anyconnect 4.x does.
You may need to buy anyconnect APEX license for your ASA to get access to download anyconnect 4 software.

Use tlsv1.2 when acting as a server (you need anyconnect 4.x for tlsv1.2)
ssl server-version tlsv1.2

Use tlsv1.2when acting as a client (you need anyconnect 4.x for tlsv1.2)
ssl client-version tlsv1.2

Select SSL ciphers for outbound connections (these may  change  over time)
ssl cipher default custom "DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES128-SHA:AES256-SHA"

Inbound tlsv1 (negate this command to disable tlsv1)
ssl cipher tlsv1 fips

Inbound tlsv1.1 ciphers (negate this command to disable tlsv1.1)
ssl cipher tlsv1.1 fips

Inbound tlsv1.2 ciphers (this is the one you should use)
ssl cipher tlsv1.2 fips

Inbound dtlsv1 (used by anyconnect 4.x)
ssl cipher dtlsv1 custom "DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES128-SHA:AES256-SHA"

Summary of commands
ssl server-version tlsv1.2
ssl client-version tlsv1.2
ssl cipher dtlsv1.2 high
ssl cipher tlsv1.2 high
ssl dh-group group14
show ssl
nmap -p 443 --script ssl-enum-ciphers X.X.X.X

Turn on RPF (block spoofing)
ip verify reverse-path interface interface_name

Remove old VPN encryption/hashing algorithms
3des and sha1 have been broken.
eg no crypto ipsec ikev1 transform-set LOW esp-3des esp-sha-hmac
Keep in mind if you have VPNs that use this transform set LOW and you removed it, you would break all of those VPNs. You should migrate them to the latest algorithms. That can turn into a bit of a project dealing with 3rd parties trying to get them to update their VPN settings.
Most VPNs are running on IKEv1 but this has been replaced by IKEv2. To migrate all your VPNs you would need to involve third parties that would turn into a project deepening on how many VPNs you have.

Find and remove "permit ip any any" type rules
Its a common one to find a FULL_INTERNET_ACCESS_GROUP or IT_ADMINS that should be removed. Another common thing people like to do is remove the global NAT so no one has internet access. You provide a NAT to your proxy server (and other servers that need a public IP), deploy the proxy with GPO forcing everyone to use the proxy. You can run into issues here with software updates and licensing etc. Most modern proxies can allow MS and adobe updates. If you are forced to use a full access group it should be time based or regularly checked that its disabled. It should only be used as a last resort. Vendors should be able to provider what ports/IPs their software needs  access to to update and license.

Principle of least privilege
https://en.wikipedia.org/wiki/Principle_of_least_privilege
It seems like a simple idea to follow. Only allow the access that is needed. However often small software vendors don't even know what ports their application uses. When IT admins are trying to get a system working they often allow too many ports or full access in an attempt to get something working. Often these "temp" rules get forgotten about and sysadmin is onto the next p1 issue. You need to replace these with rules allow the correct source + destination on the correct ports/protocols. This can turn into a project depending on how big your ruleset is. You would need to speak with each business unit and gather info on what apps are needed and create the correct rules etc.

Lock down DNS
Most malware/botnets are using multiple dns names like botnethome.cc as a way to contact the bot herder. Similar to removing the global nat. Block all DNS requests and only allow DNS requests to your authorised DNS servers. That way malware can't use 8.8.8.8 or their own public DNS server to lookup their CnC domains. Cisco umbrella is a good product here for DNS protection. Only allow DNS requests from the LAN to the cisco umbrella VA's (DNS servers). Only allow the VA's out to the cisco umbrella public DNS. All other DNS should be blocked. This way if malware tries to look up botnethome.cc it will pass through your systems where it can be logged/blocked and alert you to an issue. DNSfilter is a cheaper alternative, I haven't used it myself though 1$ per user.

Get a security company to run tests / audits
The best thing to do is get an outside security company to run scans/test/audit on your ASA. Best to contract an IT security company to run the audit. Your MSP might like to say everything is fine and they have been doing a great job keeping the FW updated. You can use your existing MSP company to fix the issues the audit raises. They will let you know what issues you have and should fix. Often these companies will just run an out of the box tool and forward you the report it generates and a nice big bill. There are many tools you can use to do it yourself for example:
https://www.titania.com/products/nipper/ (for ASA)
https://www.tenable.com/products/nessus (for general vulnerabilities) 
The advantage with using an IT security company is they will be able to explain each issue and let you know how serious it is and give advice on remediation.

Some tools work better with different firewalls. Palo alto have their own BPA tool which is free and very good.

1 comment:

  1. Nice post. Accurate, Concise and cuts through the mumbo jumbo. You saved me time digging through Cisco's documentation.

    ReplyDelete