#SecureSenses --verbose

1. CA cert request: Enrolling device requests and installs CA cert. SCEP Opertion: GetCACert HTTP Header: GET /CertSrv/mscep/mscep.dll/pkiclient.exe?operation=GetCACert&message=SCEPLab HTTP/1.0 Host: 10.0.0.6 2. SCEP server returns the CA cert: In the case of GET operation with a type of GetCACert, the MIME content type returned will  depend on whether or not an RA is in use. If there is no RA, only the CA certificate is  sent back in the response, and the response has the content type tagged as application/x-x509-ca-cert. If there is an RA, as it is the case in this lab, the RA certificates are sent back together with the CA certificates.  The content type is application/x-x509-ca-ra-cert. HTTP Header: HTTP/1.1 200 OK Content-Length: 4170 Content-Type: application/x-x509-ca-ra-cert Server: Microsoft-IIS/8.0 Date: Mon, 29 Apr 2013 09:15:51 GMT Connection: close 3. Device requests an identity certificate: SCEP Operation: PKIOperation HTTP H

1. Install CA cert ciscoasa(config)# crypto ca trustpoint CA ciscoasa(config-ca-trustpoint)# revocation-check crl ciscoasa(config-ca-trustpoint)# enrollment url http://10.0.0.6/certsrv/mscep/mscep.dll ciscoasa(config)# crypto ca authenticate CA  Debug output : CRYPTO_PKI: HTTP response header: HTTP/1.1 200 OK Content-Length: 4170 Content-Type: application/x-x509-ca-ra-cert Server: Microsoft-IIS/8.0 Date: Mon, 29 Apr 2013 11:13:14 GMT Connection: close Content-Type indicates we have received CA and RA certificates. CRYPTO_PKI:crypto_process_ca_ra_cert(trustpoint=CA) INFO: Certificate has the following attributes: Fingerprint:     537adc87 22cc6e2b 07fdf2e0 18d8ba8b The PKCS #7 message contains 4 certificates. CRYPTO_PKI:crypto_pkcs7_extract_ca_cert found cert CRYPTO_PKI: transaction GetCACert completed CRYPTO_PKI: CA certificate received. CRYPTO_PKI: crypto_pki_authenticate_tp_cert() CRYPTO_PKI: trustpoint CA authentication status = 0 Trustpoint 'CA&

ASA supports status verification using CRLs and OCSP. CRL can be retrieved using HTTP, LDAP or SCEP. Revocation checking using CRL: Over HTTP: ciscoasa(config)# crypto ca trustpoint ASDM_TrustPoint2 ciscoasa(config-ca-trustpoint)# revocation-check crl ciscoasa(config-ca-crl)# protocol http By default ASA will use address listed in CDP extension of the certificate that is being validated.  To override default behaviour we need to add the following in the CRL configuration context. ciscoasa(config-ca-crl)# policy static ciscoasa(config-ca-crl)# url 1 http://cdpurl.kp.local/crl.crl Over LDAP: Certificate I'm using for this lab, doesn't have LDAP address in its CDP extension. Therefore I'm using "policy static"  to specify LDAP URL where CRL can be retrieved.  ciscoasa(config)# crypto ca trustpoint ASDM_TrustPoint2 ciscoasa(config-ca-trustpoint)# revocation-check crl ciscoasa(config-ca-trustpoint)# crl configure ciscoasa

This procedure is largely the same as in IOS. Generate Keys: ciscoasa(config)# crypto key generate rsa general-keys modulus 1024 INFO: The name for the keys will be: Keypair generation process begin. Please wait... Verify keys have been generated: ciscoasa(config)# show crypto key mypubkey rsa Key pair was generated at: 14:56:09 UTC Apr 5 2013 Key name:  Usage: General Purpose Key  Modulus Size (bits): 1024  Key Data:   30819f30 0d06092a 864886f7 0d010101 05000381 8d003081 89028181 00c0a355 Create trustpoint for root CA: ciscoasa(config)# crypto ca trustpoint ORCA1-CA ciscoasa(config-ca-trustpoint)# enrollment terminal ciscoasa(config)# crypto ca authenticate ORCA1-CA Enter the base 64 encoded CA certificate. End with the word "quit" on a line by itself -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- quit INFO: Certificate has the following attributes: Fingerprint:     e9fd8a22 e82c13ef 5db781a7 616ad113 Do you accept this certifica

The way IOS stores certificates depends on enrolment method.  Certificates enrolled via command line or SCEP are stored in config: R1#show run | begin crypto pki certificates crypto pki certificate chain ORCA1-CA  certificate ca 37A15821A55DD2864B62A67B6EFD5429   3082038A 30820272 A0030201 02021037 A15821A5 5DD2864B 62A67B6E FD542930 Certificates installed via SDM are stored in NVRAM: R2#dir nvram: Directory of nvram:/    45  -rw-      1629                        startup-config    46  ----        7636                       private-config     1  -rw-           4                        rf_cold_starts     2  -rw-           0                        ifIndex-table     3  -rw-         910                      ORCA1-CA#5429CA.cer     4  -rw-         571                      IOS-CA-R2OUK#7401CA.cer When the built-in IOS CA server is enabled, the CA cert is stored in NVRAM.

In this post we'll go over enrolling Cisco IOS routers for certificates using terminal.   Generate keys Firstly we need to generate key pair that we'll then use to create Certificate Signing Request (CSR) that will include our public key. Here we need to decide on the key length. Security wise - the longer the better. It's never that simple though. To this day there are applications that simply do not support anything longer than 2048. This should be taken into consideration. Do we need anything longer than that? We'd have to consider the threat vector. Longer key makes factorization harder. To my knowledge as of writing 1024 bit keys have not been factored. It would take very long time and a lot of very advanced infrastructure to do. This is not a valid threat for most organizations. Key length should be considered in terms of certificate lifetime. The longer the validity the longer they. There also is the CPU overhead we need to take into account. Yes, nowaday

In a previous post I showed how I installed ACS in VBox. The reason I wanted it in VBox was so I could add it to GNS3 topology as a host. GNS uses first NIC in of a VM as a “management” NIC and adds a second NIC for linking within the topology.  ACS supports only single NIC (even the hardware appliance that comes with 4 NICs, has 3 of them disabled). “Runtime”  is the process that listens to and processes TACACS and RADIUS requests. It gets “bound” to the IP addresses configured during the initial setup. When ACS is added to GNS and second NIC installed and configured, the "runtime" still listens only on the first NICs IP address. Configuring the second NIC, disabling the first one and restarting ACS application results in "runtime" not starting at all. To get around that, I needed to do the following at the ACS’s console once ACS was added to GNS as a VBox host: 1.          Configure second NIC with the same IP address as the first one # configure term

Monitoring and alerting on failed authentication attempts is a crucial part of a security strategy. Failed authentication events may be a result of someone trying to guess or brute force passwords.   ACS is used for controlling access to network devices such as switches, routers, firewalls as well as authenticating VPN connections and wireless access. Authentication failures from ACS could alert us of an attacker trying to establish remote connection over VPN or trying to penetrate our wireless. We’ll need 3 separate alarms to notify us of: Attempts to access network devices (TACACS+ authentication failures )         Attempts to penetrate wireless or VPN (RADIUS authentication failures)            Attempts to access ACS admin interface (ACS Instance authentication failures) To configure alerting we need to go to: “Monitoring and Reports” -> “Launch Monitoring & Report Viewer”  “Alarms” -> “Thresholds”     1.        Configuring TACACS+ authentic

ACS 5.3 is supported on a hardware appliance, VMWare ESX and VMWare Server. Even though not supported, it works without modification in VMWare Player. None of the above helps us if we want to test it with switches or routers in GNS3. While version 5.2 could be installed in VirtualBox, v5.3 consistently failed installation with “Unsupported hardware” error message. After trying all possible combinations of virtual hardware in VBox it still refused to install. After some hacking I eventually managed to get working. Installation requires modification of the ISO image provided by Cisco and a bit of cheating in the kickstart file and pre-creation of partitions in the VM. We will need ISO editor (ISOpen or MagicISO), text editor (such as Notepad++) and a Linux live CD of your choice. VBox hardware configuration: OS Type: RedHat RAM: 1024 CPU: PAE/NX enabled, VT-x/AMD-V disabled Floppy: Disabled Storage: Disk 70GB (I used dynamically expanded), Controller SCSI, SCSI Port 0

There are multiple ways to secure OSPF.  The essential one is authentication. By default there isn't any validation to assure legitimacy of an OSPF topology update. Basically an attacker or a bored employee could install a physical router and become a member of a routing system. Alternately a tool such as LOKI ( http://www.ernw.de/content/e6/e180/index_eng.html ) could be used. LOKI provides a GUI and is very simple to use, I however found it a bit buggy. More on that can be found in my Attacking OSPF - route injection post. Other tools that could be used include:  SCAPY  http://www.secdev.org/projects/scapy/  - very advanced and fairly complicated packet generation tool, to craft OSPF packets it requires OSPF extension TCPREPLAY -  http://tcpreplay.synfin.net/  - a legitimate OSPF adjacency set up and database exchange could be captured, modified and replayed (I had limited success with this technique) On a Cisco router we can use the following to secure our OSPF routi