My little part of the Internet

Category: Security (Page 1 of 2)

Generating Passwords using PowerShell

Even now – after all this time – passwords are hard.

Yes, I know we should all be using Cloud with its fancy KeyStore/Key Vaults or enterprise store such as CyberArk. We all know we should not be chosing them. However, like it or not ‘things’ still need passwords. Whether its for an encryption key, wireless network or just a plain and simple password.

Vendors are also part of the problem, placing restrictions on types of characters or even positioning of them within a password. Still. In 2020! (VMware and Cisco are pretty horrific at this)

Also when you are building stuff in automation, its inevitable you will need some sort of password generating. I use PowerShell a lot and found methods that could be used to do this.

Voila my new GitHub project https://github.com/kevsterd/PoSH-Passwords

This is based on using the Psuedo Random Number Generator (PRNG) which is a feature provided by the Windows Cryptographic Service Provider (CSP) which generates randomness in a ‘good enough’ manner. If you need more than this then well you know why and what to do about it but for most uses this is pretty good.

It uses vendor safe methods and arrangments out of the box with a pretty good 16 character length. You can append flags to make it stronger, output a number of them or make them readable. Its up to you. Your choice.

# Import the module
PS > import-module .\Password-Functions.psm1

# Run the function
PS > New-Password
LC*ATg2F0CFmh-r4

Want longer length ? Want more than one ?

PS > New-Password -Length 20 -count 3
uVelF$qejS4B.J$I8hmO
I9h+Wx1fJeUw8OxWf@DA
QbvykhouQ@tHe1IuQDPE

Remember, the passwords being returned back as an object you can then store into other variables.

PS > $pass=New-Password

You can obviously use the PowerShell SecureString method to store and manipulate if need be. (Some decent tips at http://blog.majcica.com/2015/11/17/powershell-tips-and-tricks-decoding-securestring/)

PS > $pass=New-Password

PS > $secpass=(ConvertTo-SecureString $pass -AsPlainText -Force)
PS > $secpass
System.Security.SecureString

PS > $secpass | ConvertFrom-SecureString
01000000d08c9ddf0115d1118c7a00c04fc297eb010000002571feb3508bb14b8eaa7cac1828a6b80000000002000000000010660000000100002000000064fc1cf1a0b044b4a1dd63aa3fc9ba9ec4f83b24a70569cbbe25773522868bd4000000000e80000000020000200000004487a5581bbc0d7ffcb47bdfda87198014a8cce89b9ed117b1c29893e9d3481b3000000058b14398fa542e694ce5b9a37299b147f5c9640e33f4c6603b7a2131c79c23d22301870794d266ea52b5194ebdb1326a40000000db1dec8a79db34f89846c015fb6a37f4116cb15c48ccd9dcecbd8dfc16a3a1209207be1a9e53e1b37870cdf04c693ff9a41f100d5197d42d7326e4680c6941b9

PS > $secpass | ConvertFrom-SecureString | Out-File ".\MyPassword.txt"

Windows Phone 8.1 to Cisco ASA VPN – Part 2

AnyConnect-logo  Cisco have now released a BETA AnyConnect client for Windows Phone 8.1 availible here  at the Windows Phone store
I havn’t tested the latest builds but the initial version had a few showstoppers that look like to have been fixed.  Remember this uses SSL/TLS encryption only and your local security policy may mandate the use of IPsec, along with all its issues !
Also they dont appear to have fixed the session timeout bug so that may cause a few headaches with disconnects.

Windows Phone 8.1 to Cisco ASA VPN

[There is next to no information availible on this around so this was borne out of experimentation and a lot of packet capture analytics]
Update:  Since testing this I have since found that L2TP/IPsec does not work if the ASA is behind a NAT device.  This is because the WP81 device explicitly will not connect to a NAT-T device.  There is a registry key on Windows to enable this, however nothing on WP8.  
Windows Phone 8.1 introduced a Native VPN client to the operating system.  It allows L2TP/IPsec and IPSEC IKEv2 nativly, and various SSL VPN providers via plug ins downloaded from the Windows Store.  At the moment Juniper, Checkpoint and F5 have all made clients.  Sadly Cisco has not yet, although is due to release one by mid 2015.
This leaves organisations with a quandry not being able to support Windows Phone.   This is a shame as the platform appears to try to support strong authentication and encryption schemes where possible.
You would like to think that Windows Phone supporting IKEv2 and Cisco AnyConnect 3.x/4.x’s IPSEC implmentation using only IKEv2 that it would interoperate.  Sadly it does not.  The ASA – for some reason – always believes the Windows Phone to be a L2L (LAN to LAN/Site to Site) VPN.  Repeated attempts could not get this to work.
Since writing the above and reading the Cisco documentation more, you need ASA to be at 9.3(2) or above to support 3rd Party IPSec clients.
IKEv2 Proposals send from Windows Phone (just for information) are:

3DES SHA1 DH Gp 2
AES-CBC 128 SHA1 DH Gp 2
3DES SHA256 DH Gp 2
AES-CBC 128 SHA256 DH Gp 2
AES-CBC 128 SHA384 DH Gp 2

I’m still battling the ASA/WP81 connection using IKEv2 and certificates.   The configuration appears to be a little problematic and current working solutions rely on the use of EAP for the client authentication.   However, if you want to do plain, boring, RSA certificate authentication at both ends it does not work due to the ASA wanting to use RSA and the WP81 devices trying to ECDHA which the ASA dosent offer  ….. [currently talking to TAC]
This only leaves L2TP/IPsec as an option, which the ASA does support.  Effectivly this uses an IKEv1 IPSEC channel to tunnel L2TP over.  L2TP is not a very secure protocol but is very good for tunneling, but over IPSEC it should be fine for most environments.  As mentioned IKEv1 is used and the following modes are proposed from Windows Phone:

AES-CBC 256 28800  seconds SHA1 DH Gp 20
AES-CBC 128 28800 seconds SHA1 DH Gp 19
AES-CBC 256 28800 seconds SHA1 DH Gp 14
3DES 28800 seconds SHA1 DH Gp 14
3DES 28800 seconds SHA1 DH Gp 2

Testing with ASA code 9.2-ish (seems ok on 8.6-ish too), only the last mode (3DES, SHA1, DH Gp2) appears to work.   Not 100% sure of the reason, but I suspect Cisco only support DH Group 20, 19 and 14 when using IKEv2.  Thus on ASA side you need to add:

crypto ikev1 policy 5 (or whatever you have free)
 authentication rsa-sig
 encryption 3des
 hash sha
 group 2
 lifetime 28800

You then need to look at the IPSEC SA.  The ‘best’ I found to work was using AES128 with SHA1 hash.   The Windows client differs to a standard client in that it uses TRANSPORT mode, as apposed to TUNNEL mode.  Windows also has some values for SA lifetimes that need to be used.  Thus ASA config needs the following:

! Note:  My ASA external interface is called 'outside', YMMV
crypto dynamic-map outside_dyn_map 60000 set ikev1 transform-set ESP-AES-128-SHA-TRANS ESP-3DES-SHA-TRANS
crypto dynamic-map outside_dyn_map 60000 set security-association lifeftime seconds 3600
crypto dynamic-map outside_dyn_map 60000 set security-association lifeftime kilobytes 250000
! Note: No PFS is supported
! Note: NAT-T is enabled by default.

I could have ammended the standard dynamic crypto map to include these values but decides to keep it seperate.
Next challenge is authentication.   The ASA supports Certificate based, but Windows Phone only supports Pre Shared Key along with username and password.  This can be passed to whatever AAA solution you may have defined within the ASA (such as Active Directory/RADIUS/even SecurID) or could be a local username and password.   Also the L2TP/IPsec profile does not support the concept of a ‘group’ (which can be used to map to an ASA connection profile) thus the DefaultRAGroup has to be used.  Heres hoping haven’t used this group for any of your client access 🙂   If you have then you need to be very careful to break any existing access.
First you need to create a new group policy to attatch to the group

group-policy GP-WinPhone internal
group-policy GP-WinPhone attributes
 wins-server none
 dns-server value 10.x.x.x 192.168.x.x
 vpn-tunnel-protocol l2tp-ipsec
 pfs enable
 default-domain value yourdomain.local

This sets the protocol, client domain servers and name.  Next update the tunnel group

tunnel-group DefaultRAGroup general-attributes
 address-pool OneOfYourPools
 default-group-policy GP-WinPhone
 authentication-server-group LOCAL
 ! Set a different group here depending on local security policy
tunnel-group DefaultRAGroup ipsec-attributes
 ikev1 pre-shared-key xxxxxxxxxx
 isakmp keepalive disable
tunnel-group DefaultRAGroup ppp-attributes
 no authentication ppp
 no auuthentication ms-chap-v1
 authentication ms-chap-v2

This should be enough apart from adding a new local user for authentication.  In the above I used the local user database.

username myWinPhoUser password xxxxxxxxx nt-encrypted
username myWinPhoUser attributes
 service-type remote-access

That should get you a working connection ASA side.
From the Windows Phone side configure from Settings > VPN > Add:
wp_ss_20150223_0002  wp_ss_20150223_0001 wp_ss_20150223_0003 wp_ss_20150223_0004
You can decide to set a Proxy as need be.  As discussed before, there is no way to use L2TP/IPsec without a username and password being set.  So you may as well use them either using a local user as additional Pre Shared Key or Active Directory Username and Password as additional authentication.
Good luck !

CISSP

Finally had notification that I now am offically CISSP certified !

I’m not a certification chaser but decided late last year I wanted to do something different to pure technical qualifiactions.  It was a very long (6 hour/250 questions – some interative) exam and certification process but now all done.  Very happy.
Next is keeping up with various things to gain CPE’s
I think Certified Ethical Hacker (CEH) next……

Private Network Address ranges

Most people will be familiilar with the RFC 1918 standard for private network addressing.
Reading through a lot of the RFC’s, they have now been superceeded with later versions.  The most current appears to be RFC6890 although badly formatted into tables.   The prior version RFC5735 has a section 4 which is much more usable.

Address Block       Present Use                Reference
 ------------------------------------------------------------------
 0.0.0.0/8           "This" Network              RFC 1122, Section 3.2.1.3
 10.0.0.0/8          Private-Use Networks       RFC 1918
 127.0.0.0/8         Loopback                    RFC 1122, Section 3.2.1.3
 169.254.0.0/16      Link Local                  RFC 3927
 172.16.0.0/12       Private-Use Networks        RFC 1918
 192.0.0.0/24        IETF Protocol Assignments   RFC 5736
 192.0.2.0/24        TEST-NET-1                  RFC 5737
 192.88.99.0/24      6to4 Relay Anycast          RFC 3068
 192.168.0.0/16      Private-Use Networks        RFC 1918
 198.18.0.0/15       Network Interconnect
                     Device Benchmark Testing    RFC 2544
 198.51.100.0/24     TEST-NET-2                  RFC 5737
 203.0.113.0/24      TEST-NET-3                  RFC 5737
 224.0.0.0/4         Multicast                   RFC 3171
 240.0.0.0/4         Reserved for Future Use     RFC 1112, Section 4
 255.255.255.255/32  Limited Broadcast           RFC 919, Section 7
                                                 RFC 922, Section 7

For DEV, LAB and TEST networks this shows two more segments that can be used (198.51.100.0/24 and 203.0.113.0/24) along with one I have used often 192.0.2.0/24.
Its amazing how ofter I have come accross organisations not taking these into account when planning schemes.

New Standards – HTTP2

A great article I came accross explaining how HTTP2 works is availible at http://daniel.haxx.se/http2/http2-v1.6.pdf
It has some intresting challenges for adoption and implications for Network Security and vendors of the associated devices used to secure them.  One of the main challenges being that the format moves from an easy to read text form, to a binary blob.  This means Deep Packet Inspection (DPI) of these frames becomes a lot more intensive.
It will also be interesting how this gets adopted for the ‘average’ site.   I can see the Goog, Facebook and Microsoft adopting it but how long did it take for HTTP 1.1 to become adopted ?
One to monitor……
 

So that went well…… The pains of multi factor Authentication

First day in my ‘post a day’ challenge for November went well with me missing a post…so I shall indevor to catch back up 🙂  ..
There is a few reasons for this but one of the reasons is that I can’t just post from any device.  I took the plunge a good while back and protect the site using the fantasic Duo Security two factor authentication system which means I have to have my phone to hand when logging into my Blog.

Yes, multi factor authentication is a  pain in the ass but thats security.  Its about balancing security with usability.  I’d rather have the pain than allowing someone else to blog as me.
I also recomend using two factor authentication for all of your ‘primary’ accounts such as Microsoft (Technet, Outlook, Office 365), Google (+, gMail, Webmaster Tools), Apple  (iTunes, iCloud), Twitter and Facebook.   Using Windows Phone, I use the Microsoft Authenticator app which can be used for all of the sites listed here.
Logging on can be a pain, but I’d rather have the extra security.

Native Apple iOS Client and Android Client to Cisco ASA VPN using Certificate Authentication Part 4 – More ASA Side

Some parts I forgot from the last few posts.
The ASA also uses Group Policy (not AD group policy!) configuration.  In here you set useful things such as DNS, domain and other properties.  Its also the area to configure specifics for the IPSEC Phase 2 connection.   I normally use a GP per connection as its allows some flexibility when making changes later on.  You can also set some values within the default group policy that will be standard over the whole of your ASA, which depending on if inherit is turned on or not get set.
For Apple iOS devices IP Compression and PFS have to be turned on.  On Android, these are not.  You get a strange symptom (if set) where the Android handset claims its connected (and the ASA even issues an IP address) but the device never shows connected in ASDM.  It was only with use of various debugs that I managed to find this out.
Group policies therefore are:

!Apple iOS
group-policy GP_iOS internal
group-policy GP_iOS attributes
 dns-server value 10.100.200.10 10.100.202.10
 vpn-session-timeout none
 vpn-tunnel-protocol ikev1
 ip-comp enable
 pfs enable
 default-domain value mydomain.local
!Android
 group-policy GP_ANDR internal
 group-policy GP_ANDR attributes
  dns-server value 10.100.202.10 10.100.200.10
  vpn-session-timeout none
  vpn-tunnel-protocol ikev1
  default-domain value mydomain.local

That should complete all of the configuration requried to allow iOS and Android devices to connect to a Cisco ASA using the inbuilt native IPSEC client using x509 certificates.   You really arn’t using Pre Shared Keys in this day and age are you ?

Putty – Session Logs

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 !

Native Apple iOS Client and Android Client to Cisco ASA VPN using Certificate Authentication Part 3 – ASA Side

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

« Older posts

© 2024 Kevsters Blog

Theme by Anders NorénUp ↑