Recently I posted about IOS CA, taking this further I enrolled one router of mine to one sub CA and other router to other sub CA. Is that even at all possible? The certificates share a common chain...
They share a common CA - but have different OU field.
Server:
----------------------------------
ez-server#sh cry ca cert
Certificate
Issuer:
cn=SUBCA1.cisco.com
ou=LAB
Subject:
Name: ez-server.cisco.com
CA Certificate
Issuer:
cn=CA.cisco.com
ou=LAB
Subject:
cn=SUBCA1.cisco.com
ou=LAB
----------------------------------
Client cert:
------------------------------
ez-client#sh cry pki cert
Certificate
Issuer:
cn=SUBCA2.cisco.com
ou=LAB1
Subject:
Name: ez-client.cisco.com
CA Certificate
Issuer:
cn=CA.cisco.com
ou=LAB
Subject:
cn=SUBCA2.cisco.com
ou=LAB1
------------------------------
Already wrong? Damn...
http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_easy_vpn_rsa.html#wp1056030
"The content of the first Organizational Unit (OU) field will be used as the group."
Monday, December 28, 2009
Saturday, December 26, 2009
ASA/PIX packet capture feature.
If you ever worked with Cisco TAC on an ASA/PIX case chances are you've needed to capture packets.
Command reference:
http://www.cisco.com/en/US/docs/security/asa/asa80/command/reference/c1.html#wp2108895
ASP capture.
Here's a few interesting options you typically use to diagnose problems. You will see whole combos of them when working with TAC.
A firewall by definition is a device which is supposed to drop packets - chances are that it's dropping way too many of them. If you want to check out what your ASA is dropping, there's a perfect tool for you - type asp-drop capture.
---------------------
capture CAPASP type asp-drop all
---------------------
This will show you all the packets dropped by Accelerated Security Path - ASA/PIX's equivalent of CEF, so to speak ;-)
Depending on the version you might also see the exact asp drop type that caused a given packet to drop (as seen in output of "show asp drop")
Interface capture
Chances are that you will need to see packets on the "inside" and "outside" interface. Nothing easier, you can attach separate capture on separate interfaces with separate options. However it's best practice to:1) Create an access-list matching interesting traffic.
2) Remember about packet size.
3) Remember about size of capture (all of it is stored in RAM).
4) If the capture is going to be there for a while - consider using circular buffer (wrap around buffer)
A well thought capture:
---------------
capture CAPIN interface inside access-list CAPACL packet-len 1500 circular-buffer buffer 10000000
----------------
We'll be using ~10MB buffer (RAM) to capture traffic on interface inside which is matching access-list ACL and be sure to capture 1500 first bytes of packet (otherwise 64 bytes used). If the buffer space is finished wrap the buffer around.
The elusive "trace detail" option.
It's a nice one, but was known to cause problems. Are you familiar with packet-tracer? Imagine having same information attached to you capture.
capture TRACE trace details {more options here}
After capturing the data you're interested in.
show capture TRACE trace (/decode).
Chances are you're going to get too much information for your own good here, and hey maybe even crash the box.
Last but not least
Exporting captures:
https://{ip_address_of_ASA}/capture/{Name_of_capture}/pcap
or
(from system context if multicontext):
copy /pcap capture:{context_name}/{capture_name} ....
Why the "pcap"? You need it if you want to look deep inside a packet.
Well if you don't use it chances are the most advanced problems will not get solved.
And REMEMBER if you're creating a packet capture, for a problem that also needs some debugs taken, make sure that the debugs are taken at the same time the captures are? If you don't you're making everyone's life hard.
Command reference:
http://www.cisco.com/en/US/docs/security/asa/asa80/command/reference/c1.html#wp2108895
ASP capture.
Here's a few interesting options you typically use to diagnose problems. You will see whole combos of them when working with TAC.
A firewall by definition is a device which is supposed to drop packets - chances are that it's dropping way too many of them. If you want to check out what your ASA is dropping, there's a perfect tool for you - type asp-drop capture.
---------------------
capture CAPASP type asp-drop all
---------------------
This will show you all the packets dropped by Accelerated Security Path - ASA/PIX's equivalent of CEF, so to speak ;-)
Depending on the version you might also see the exact asp drop type that caused a given packet to drop (as seen in output of "show asp drop")
Interface capture
Chances are that you will need to see packets on the "inside" and "outside" interface. Nothing easier, you can attach separate capture on separate interfaces with separate options. However it's best practice to:1) Create an access-list matching interesting traffic.
2) Remember about packet size.
3) Remember about size of capture (all of it is stored in RAM).
4) If the capture is going to be there for a while - consider using circular buffer (wrap around buffer)
A well thought capture:
---------------
capture CAPIN interface inside access-list CAPACL packet-len 1500 circular-buffer buffer 10000000
----------------
We'll be using ~10MB buffer (RAM) to capture traffic on interface inside which is matching access-list ACL and be sure to capture 1500 first bytes of packet (otherwise 64 bytes used). If the buffer space is finished wrap the buffer around.
The elusive "trace detail" option.
It's a nice one, but was known to cause problems. Are you familiar with packet-tracer? Imagine having same information attached to you capture.
capture TRACE trace details {more options here}
After capturing the data you're interested in.
show capture TRACE trace (/decode).
Chances are you're going to get too much information for your own good here, and hey maybe even crash the box.
Last but not least
Exporting captures:
https://{ip_address_of_ASA}/capture/{Name_of_capture}/pcap
or
(from system context if multicontext):
copy /pcap capture:{context_name}/{capture_name} ....
Why the "pcap"? You need it if you want to look deep inside a packet.
Well if you don't use it chances are the most advanced problems will not get solved.
And REMEMBER if you're creating a packet capture, for a problem that also needs some debugs taken, make sure that the debugs are taken at the same time the captures are? If you don't you're making everyone's life hard.
IOS CA
Recent topic I've been dealing with is certificates. I'll assume here that everyone knows what a certificate and how PKI works.
This is useful for CCIE Security study.
First step is to setup a CA server.
And what's easier then setting it up on IOS router? Frankly many things ... so let's have a look on how it's done.
First of all generate RSA keys - I'd suggest to used named keys, general-purpose and exportable, usually over 1024 bytes (SSH v2 requires over 786 byte key size).
Let's do this:
--------------------------------------------------
Router>
Router>ena
Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#hostname CA
CA(config)#ip domain-name cisco.com
CA(config)#crypto key generate rsa modulus 1024 general-keys exportable label cisco
The name for the keys will be: cisco
% The key modulus size is 1024 bits
% Generating 1024 bit RSA keys, keys will be exportable...[OK]
CA(config)#
*Dec 26 19:17:22.167: %SSH-5-ENABLED: SSH 1.99 has been enabled
CA(config)#cry key export rsa cisco pem url nvram: 3des cisco123
% Key name: cisco
Usage: General Purpose Key
Exporting public key...
Destination filename [cisco.pub]?
Writing file to nvram:cisco.pub
Exporting private key...
Destination filename [cisco.prv]?
Writing file to nvram:cisco.prv
--------------------------------------------------
We can finally get to setup the CA server. It's very easy to set is up.
Create PKI server, " no shut" it and enable http server:
--------------------------------------------------
CA(config)#cry pki server CA
CA(cs-server)#no shut
%Some server settings cannot be changed after CA certificate generation.
% Please enter a passphrase to protect the private key
% or type Return to exit
Password:
Re-enter password:
% Generating 1024 bit RSA keys, keys will be non-exportable...[OK]
% Exporting Certificate Server signing certificate and keys...
CA(cs-server)#exit
CA(config)#ip http server
*Dec 26 19:21:36.715: %PKI-6-CS_ENABLED: Certificate server now enabled.
CA(config)#do sh cry pki server
Certificate Server CA:
Status: enabled
State: enabled
Server's configuration is locked (enter "shut" to unlock it)
Issuer name: CN=CA
CA cert fingerprint: 35035E5A 8C43B8EB 16A63A47 B65526F7
Granting mode is: manual
Last certificate issued serial number (hex): 1
CA certificate expiration timer: 19:21:23 CET Dec 25 2012
CRL NextUpdate timer: 01:21:23 CET Dec 27 2009
Current primary storage dir: nvram:
Database Level: Minimum - no cert data written to storage
--------------------------------------------------
From now on you can point anything SCEP capable to http://{IP_address_of_CA_router}:80.
But to o honest a CA server configured like this is not that functional. It will work, it has sane defaults, but it's best tweak it a bit. Here's a set I would recommend (for closed deployment, no access from outside).
--------------------------------------------------
crypto pki server CA
database level complete
database archive pem password 7 01100F175804575D72
issuer-name cn=CA.cisco.com,OU=LAB
grant auto rollover ca-cert
cdp-url http://cs-addr/cgi-bin/pkiclient.exe?operation=GetCRL
--------------------------------------------------
Why the interesting cdp url? Non-SCEP clients eager to get CRL.
http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_cfg_mng_cert_serv_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1193861
Note: you will need to do ctrl+v before putting in "?" sign in the URL.
Last step, how to configure SUB CA to this CA server?
--------------------------------------------------
crypto pki server SUBCA
database level complete
database archive pem password 7 045802150C2E1D1C5A
issuer-name cn=SUBCA1.cisco.com,ou=LAB
grant auto rollover ca-cert
mode sub-cs
shutdown
crypto pki trustpoint SUBCA
enrollment url http://10.0.0.1:80
revocation-check crl
--------------------------------------------------
Note: you should only unshut the subca once the enrollment url is specified.
The subca will automatically enroll to CA - depending on version you might need or not to grant the subca certificate on CA server.
Note: If you configured enrollment url under trustpoint it is expected that a query for SCEP capability will be done when a certificate is used. If this is not desired (issues with delays etc), you can change enrollment url to enrollment terminal to make sure this is not done.
This is useful for CCIE Security study.
First step is to setup a CA server.
And what's easier then setting it up on IOS router? Frankly many things ... so let's have a look on how it's done.
First of all generate RSA keys - I'd suggest to used named keys, general-purpose and exportable, usually over 1024 bytes (SSH v2 requires over 786 byte key size).
Let's do this:
--------------------------------------------------
Router>
Router>ena
Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#hostname CA
CA(config)#ip domain-name cisco.com
CA(config)#crypto key generate rsa modulus 1024 general-keys exportable label cisco
The name for the keys will be: cisco
% The key modulus size is 1024 bits
% Generating 1024 bit RSA keys, keys will be exportable...[OK]
CA(config)#
*Dec 26 19:17:22.167: %SSH-5-ENABLED: SSH 1.99 has been enabled
CA(config)#cry key export rsa cisco pem url nvram: 3des cisco123
% Key name: cisco
Usage: General Purpose Key
Exporting public key...
Destination filename [cisco.pub]?
Writing file to nvram:cisco.pub
Exporting private key...
Destination filename [cisco.prv]?
Writing file to nvram:cisco.prv
--------------------------------------------------
We can finally get to setup the CA server. It's very easy to set is up.
Create PKI server, " no shut" it and enable http server:
--------------------------------------------------
CA(config)#cry pki server CA
CA(cs-server)#no shut
%Some server settings cannot be changed after CA certificate generation.
% Please enter a passphrase to protect the private key
% or type Return to exit
Password:
Re-enter password:
% Generating 1024 bit RSA keys, keys will be non-exportable...[OK]
% Exporting Certificate Server signing certificate and keys...
CA(cs-server)#exit
CA(config)#ip http server
*Dec 26 19:21:36.715: %PKI-6-CS_ENABLED: Certificate server now enabled.
CA(config)#do sh cry pki server
Certificate Server CA:
Status: enabled
State: enabled
Server's configuration is locked (enter "shut" to unlock it)
Issuer name: CN=CA
CA cert fingerprint: 35035E5A 8C43B8EB 16A63A47 B65526F7
Granting mode is: manual
Last certificate issued serial number (hex): 1
CA certificate expiration timer: 19:21:23 CET Dec 25 2012
CRL NextUpdate timer: 01:21:23 CET Dec 27 2009
Current primary storage dir: nvram:
Database Level: Minimum - no cert data written to storage
--------------------------------------------------
From now on you can point anything SCEP capable to http://{IP_address_of_CA_router}:80.
But to o honest a CA server configured like this is not that functional. It will work, it has sane defaults, but it's best tweak it a bit. Here's a set I would recommend (for closed deployment, no access from outside).
--------------------------------------------------
crypto pki server CA
database level complete
database archive pem password 7 01100F175804575D72
issuer-name cn=CA.cisco.com,OU=LAB
grant auto rollover ca-cert
cdp-url http://cs-addr/cgi-bin/pkiclient.exe?operation=GetCRL
--------------------------------------------------
Why the interesting cdp url? Non-SCEP clients eager to get CRL.
http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_cfg_mng_cert_serv_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1193861
Note: you will need to do ctrl+v before putting in "?" sign in the URL.
Last step, how to configure SUB CA to this CA server?
--------------------------------------------------
crypto pki server SUBCA
database level complete
database archive pem password 7 045802150C2E1D1C5A
issuer-name cn=SUBCA1.cisco.com,ou=LAB
grant auto rollover ca-cert
mode sub-cs
shutdown
crypto pki trustpoint SUBCA
enrollment url http://10.0.0.1:80
revocation-check crl
--------------------------------------------------
Note: you should only unshut the subca once the enrollment url is specified.
The subca will automatically enroll to CA - depending on version you might need or not to grant the subca certificate on CA server.
Note: If you configured enrollment url under trustpoint it is expected that a query for SCEP capability will be done when a certificate is used. If this is not desired (issues with delays etc), you can change enrollment url to enrollment terminal to make sure this is not done.
Welcome.
This blog is intended to document all interesting stuff related to configuring and dealing with routers, firewalls and other network equipment. I'll try to document interesting stuff I worked on and give tips on probably improvements.
Hopefully this will be help people save some time.
Hopefully this will be help people save some time.
Subscribe to:
Posts (Atom)
