A useful feature when you are working on multiple devices is to keep as session log for every session. You can then easilly see what you have typed or provide evidence.
To configure this for every session:
1) Open Putty
2) Select the Default Settings and press Load
3) Navigate to Session > Logging
4) Set the Log file name in a format that makes sence to you. You can see mine
5) Navigate back to the sessions, making sure Default Settings is still highlighted and then press Save
Test !
Month: November 2013
So based on the last post, you can now start to configure the ASA to support Apple IOS and Andoid devices.
Firstly we need to add an IKEv1 policy to allow the IKE Phase 1 to establish:
!Andoid crypro ikev1 policy 10 authentication rsa-sig encryption aes-256 hash sha group 2 lifetime 28800 !IOS crypro ikev1 policy 12 authentication rsa-sig encryption aes-256 hash sha group 5 lifetime 3600
This allow the device to at least connect to the ASA to authenticate.
There is an assumption that your ASA already has installed and trust’s the CA’s that the client device certificates are issued by. This is out of scope for here however its imperative that this is in place. Its also crazy if you havent got CRL processing in place but you should know that as well.
From a ASA profile perspective its simple. As stated before both Andoid and IOS only support IKE v1 so you have to create IKEv1 profiles for these connections. The strange part of defining an IKEv1 profile is that is has to have a AAA entry set. In my case I normally define a new AAA group that has no authentication.
aaa-server NO_USER_AUTH protocol http-form
This can then be applied to a new profile. Its not used for authentication (remember – you are using Cerificates only) thus
tunnel-group IOSandAND type remote-access tunnel-group IOSandAND general-attributes ! Clients will use addressing from the named pool shown address-pool IOSandAND-Pool ! Dont use any client authentication (other than Certificate) authentication-server-group NO_USER_AUTH ! Group policy applied for connection default-group-policy GP_IOSandAND tunnel-group IOSandAND ipsec-attributes ! Define CA that client connections will be signed by ikev1 trust-point MyCA.key ! Define no user authentication ikev1 user-authentication none
Depending on if you use DAP etc (and you really should) you will have to add basic policy to allow Andoid and IOS devices to connect. There are no posture checks availible for native clients due to what the clients expose. If you want to do this then the client will need to use the AnyConnect client (free), will need a AnyConnect Mobility licence for the ASA (circa £500) and you can then use IKEv2 which negates a lot of this configuration.
Anyway hope it helps some of you
So the previous thread we were discussing Apple iOS. Now you may have had the same issues with Andoid with it becomming more popular.
First issue when configuring the ASA is the IKEv1 key exchange that goes on. When a device attempts to connect, the client is asked to provide all of the key schemes that it supports. Android 4.1+ and IOS 7 give out (in order)
Android
| AES-CBC | 256 | Seconds | 28800 | SHA1 | DH Gp 2 |
| AES-CBC | 256 | Seconds | 28800 | MD5 | DH Gp 2 |
| AES-CBC | 128 | Seconds | 28800 | SHA1 | DH Gp 2 |
| AES-CBC | 128 | Seconds | 28800 | MD5 | DH Gp 2 |
| 3DES-CBC | Seconds | 28800 | SHA1 | DH Gp 2 | |
| 3DES-CBC | Seconds | 28800 | MD5 | DH Gp 2 | |
| DES-CBC | Seconds | 28800 | SHA1 | DH Gp 2 | |
| DES-CBC | Seconds | 28800 | MD5 | DH Gp 2 |
iOS 7
| AES-CBC | 256 | Seconds | 3600 | SHA1 | DH Gp 5 |
| AES-CBC | 256 | Seconds | 3600 | SHA1 | DH Gp 2 |
| AES-CBC | 128 | Seconds | 3600 | SHA1 | DH Gp 2 |
| AES-CBC | 256 | Seconds | 3600 | MD5 | DH Gp 5 |
| AES-CBC | 256 | Seconds | 3600 | MD5 | DH Gp 2 |
| AES-CBC | 128 | Seconds | 3600 | MD5 | DH Gp 2 |
| 3DES-CBC | Seconds | 3600 | SHA1 | DH Gp 2 | |
| 3DES-CBC | Seconds | 3600 | MD5 | DH Gp 2 | |
| DES-CBC | Seconds | 3600 | SHA1 | DH Gp 2 | |
| DES-CBC | Seconds | 3600 | MD5 | DH Gp 2 |
Now we have these values we can look at configuring the ASA to support native IOS and Andoid clients using x509 Certificate authentication. Its pretty obvious that the top one is the most secure, trailing off to blatantly insecure…….
Time for post 3……..
Recent Comments