Friday, December 1, 2017

F5 disconnect issues due to time mismatch

Working with the F5-LTM within a  device cluster ,  a "disconnect" issues are bound to always come up.


One simple reason that's commonly over looked ; "if the devices time value are  far off , they two LTM will show a disconnected stated"


This will keep the two device device-trust from synchronizing since the  device-certificate would be to far spread between the two. NTP and clock-sync is a must within a F5-LTM.



Here's a typical f5-ltm  error for clock . This system is over 2+ years off.




Using the  unix date command ( from within the LTM bash shell )  we will adjust the system clock to the correct time. As soon as the time is corrected,  the  F5-LTM will reconnect and the disconnected status will vanish.
 







Ken Felix







 
 
NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
     ^      ^
=(  @  @ )=
         o 
        /  \

Wednesday, November 29, 2017

fortitoken mobile app lockout

The fortitoken  mobile app  for example is available  from the google-playstore &  has enhance security  functions

  • fingerprint ID'ing ( optional )
  • pin ( 4 digits  only )
  • and lockout if you  execute 10 PIN insertion failures ( no controls on setting the max-failures )

First let's look at a simple  fortitoken activate and binding to a local vpn user name testtoken







The mobile app is available from the app store for downloading and only needs you to supply the activation code  and assign a name for the account




the app stored named for the account DOES NOT NEED TO MATCH THE local fortigate users 







Login into the  portal and for a quick test. Upon 1st factor you will have a input box for the token. The current OTP from the mobile app screen would be 

Now , if you mobile device is lost or stolen and some one fat fingers the passcode 10 times it will wipe itself. Before  the reset, the  mobile-app will warning you at the 8th 9th intervals.








































































































































That's the final security measures for fails PINs. If  this happens to your end_user ,you only need to reactivate the  mobil-app and token.






Ken  Felix










NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
     ^      ^
=(  @  @ )=
         o 
        /  \
 

NXOS N9000 epld image upgrade

Here's a quick and short blog on how you  do a image upgrade and  upgrading the NX-OS epld image.


You should always delete old epld and images to ensure bootflash has enough space


Here I’m copying my  images from  a usb-drive into bootflash for later execution




LAB-N9K-2# copy usb1:nxos.7.0.3.I4.7.bin bootflash:


Copy progress 100% 702663KB


Copy complete, now saving to disk (please wait)...


LAB-N9K-2# copy usb1:n9000-epld.7.0.3.I4.7.img bootflash:


Copy progress 100% 99499KB



Always read any  release notes for the image and epld notes before any system upgrades, beadvise the  system will reboot automatically after the  execution of the install  epld and if the epld was installed 100% successfully.

A complete upgrade on Nexus 9396PX took approx.  10-15mins from start to finish. The more modules you have ,  will create a longer duration for the upgrade.




Execute a show  epld status after the reboot for more details



Ken Felix


NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
     ^      ^
=(  @  @ )=
         o 
        /  \






Monday, November 20, 2017

SSL state cache MSIE

In this past blog I demo how to reset the SSL cache CA for a website

http://socpuppet.blogspot.com/2017/11/ssl-cert-caching-for-mitm-inspections.html


In  MSIE ( microsoft Internet Explorer and Chrome ) it seems these browser always shows the correct CAchain issuer for the webserver when you are or are not behind a MiTM proxy.

 Take www.google.com

(  the left shows  the corp trusted CAchain )  and ( right shows the real CAchain )




Again, knowing the true certificate issuer, you can easily determine if a website  has a proxy inspection thing going on.







NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
     ^      ^
=(  @  @ )=
         o 
        /  \
 

juniper SRX & JumpCloud dynamic vpn with NCP

The NCP remote vpn client is a  great client. Simple  to build proposals and user profiles. One negative tho,  you can not  export existing profile with ease.


I will show you howto do a ike group-based vpn . It's similar to  standard dynamic-group-vpn,  but the  ike user type is set to shared

e.g 
set security ike gateway myvpngw  dynamic ike-user-type shared-ike-id      <-------


I will explain the difference on shared-ike-id vr user+group later.

Here's  a few details of the platforms involved from the  VPNserver and RADIUS-aaS


JUNOS 15.1X49-D110.4

NCP Macosx  verson3   rev35061

AUTH XAUTH

RADIUS_REMOTE  ( JUMPCLOUD )



For this vpn  settings, I  decided to use defined proposal of AES256 with  auth md5/sha1/sha256 types which we will use in the NCP client settings

ike

set security ike proposal AES256SHA1 authentication-method pre-shared-keys
set security ike proposal AES256SHA1 dh-group group5
set security ike proposal AES256SHA1 authentication-algorithm sha1
set security ike proposal AES256SHA1 encryption-algorithm aes-256-cbc
set security ike proposal AES256MD5 authentication-method pre-shared-keys
set security ike proposal AES256MD5 dh-group group5
set security ike proposal AES256MD5 authentication-algorithm md5
set security ike proposal AES256MD5 encryption-algorithm aes-256-cbc
set security ike proposal AES256SHA256 authentication-method pre-shared-keys
set security ike proposal AES256SHA256 dh-group group5
set security ike proposal AES256SHA256 authentication-algorithm sha-256
set security ike proposal AES256SHA256 encryption-algorithm aes-256-cbc


NOTE  BCPs suggest  using dhgrp 14 or stronger, but to support clients who  might have a   older vpn-client software I'm using  PFS+group5

IPSEC

set security ipsec proposal AES256SHA256 protocol esp
set security ipsec proposal AES256SHA256 authentication-algorithm hmac-sha-256-128
set security ipsec proposal AES256SHA256 encryption-algorithm aes-256-cbc
set security ipsec proposal AES256SHA256 lifetime-seconds 3600
set security ipsec proposal AES256SHA1 protocol esp
set security ipsec proposal AES256SHA1 authentication-algorithm hmac-sha1-96
set security ipsec proposal AES256SHA1 encryption-algorithm aes-256-cbc
set security ipsec proposal AES256SHA1 lifetime-seconds 3600
set security ipsec proposal AES256MD5 protocol esp
set security ipsec proposal AES256MD5 authentication-algorithm hmac-md5-96
set security ipsec proposal AES256MD5 encryption-algorithm aes-256-cbc
set security ipsec proposal AES256MD5 lifetime-seconds 3600


=======================================================

Now to wrap this up you need to set the ike and ipsec policies for the gateway


set security ike policy ike_pol_wizard_dyn_vpn mode aggressive
set security ike policy ike_pol_wizard_dyn_vpn proposals AES256MD5
set security ike policy ike_pol_wizard_dyn_vpn proposals AES256SHA1
set security ike policy ike_pol_wizard_dyn_vpn proposals AES256SHA256
set security ike policy ike_pol_wizard_dyn_vpn pre-shared-key ascii-text  "mystrongpsk"


 set security ipsec policy ipsec_pol_wizard_dyn_vpn perfect-forward-secrecy keys group5
set security ipsec policy ipsec_pol_wizard_dyn_vpn proposals AES256SHA256
set security ipsec policy ipsec_pol_wizard_dyn_vpn proposals AES256SHA1
set security ipsec policy ipsec_pol_wizard_dyn_vpn proposals AES256MD5
set security ipsec vpn wizard_dyn_vpn ike gateway gw_wizard_dyn_vpn



Now the fun starts, you will  need to set the remote-access-profile to use your   jumpcloud radius servers  and set the  src_ipv4 address for the radius-client


set access profile remote_access_profile authentication-order radius
 set access profile remote_access_profile client socpuppets firewall-user password "$9$r47KLxVwY2oJYgJDiH5TRhSyvWLxN"
set access profile remote_access_profile address-assignment pool dyn-vpn-address-pool
set access profile remote_access_profile radius-server 104.154.91.253 port 1812
set access profile remote_access_profile radius-server 104.154.91.253 secret "$9$RFcSKML7-dwY5QESyeLXUjHq.53nCtu129K8Xx-d"
set access profile remote_access_profile radius-server 104.154.91.253 source-address 10.10.10.98
set access profile remote_access_profile radius-server 104.196.54.120 port 1812
set access profile remote_access_profile radius-server 104.196.54.120 secret "$9$esuW7-wYg4JG/CKW8xbwmfTzF/pu1RKr0B7Vwsg4"
set access profile remote_access_profile radius-server 104.196.54.120 source-address 10.10.10.98
set access firewall-authentication pass-through default-profile remote_access_profile


In the jumpcloud portal, you have to define the radius-client and set the shared secret and have remote-users defined







NOTE: you can execute a unix-shell and tcpdump on your interface that sends the  radius-access-request to look for radius reject or access messages,  and to confirm the radius-requests are actually going out from the Juniper SRX to the RADIUS-aaS platform.






( a no-success  login )




( a  success  login )






The NCP-vpn-client-side is configured very easily,  by setting both a IKE and IPSEC proposals and defined these in your NCP profiles.


e.g defined IPSEC transform and IKEproposals











user details;



You remember the shared-ike-id thing,  that  I mention earlier ?




When  you connect into the SRX,  the  NCPvpnclient identity would be just the client-ipv4-addr and the groupname.

e.g  IKE  SA details  ( shared-ike-id)






vrs  the typical user+group-ike-id combination




The one cool item about the NCP client, it can   display almost too much details for logging and diagnostics purposes.





Here's the final  vpn configuration for dynamic-vpn









NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
     ^      ^
=(  @  @ )=
         o 
        /  \

Friday, November 17, 2017

locking down the SSLVPN based on geoip

Using the SSLVPN and portals,  you sometime want to banned certain locations by GEOIPs.

Example, let's says your a Enterprise-Org that has a presences in only one country/continent and your users based resides in just that continent.

By using a null group and  portal, you can easily locked down your fortinet forticlients to only that geo-ip-range thats allowed or even a  network-subnet or ip-range.

E.g  we are only allow US geoips to access our network, all others will be blocked.







By using  the cli-cmd  diag debug application sslvpn -1  we can validate what rules and groups




As you can see I matched rule-auth #2   was not allowed SSLVPN access  to any portal. So a client trying to come via a banned  geo-address will be delivered a non-existence portal named none








In the next example we are allowing our PBXeng team access but only from the firewall.address named PBX_vendors    network










 !!!!  Be cautious of  the ordering of the auth-rules  !!!!


Ken Felix






NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
     ^      ^
=(  @  @ )=
         o 
        /  \

FortiClient locked ?

Have you played with fortiClient? if yes you might run into the "locked stated" This allow you very limited or restricted  access to the vpn-client.

Here on a MACOSX client you get the  bottom left "session lock message"




You have to use the "disconnect" option  



Ken    Felix




NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
     ^      ^
=(  @  @ )=
         o 
        /  \

SSL cert caching for MiTM inspections

Firefox and a host of other  browsers  are notorious for  caching SSL certificates in the trust-chain.

This can lead to  mis-information  when doing any diagnostics/debugging &  if you  using a browser and actually inspect  the cert-chain for the trusteded-CA for a website.


Take my day-job which has a bluecoatSGproxy for SSL inspection  & we have a trusted  entrerprised-CA-cert that's present in the chain for pcgus  { aus-web.gateway.pcgus.com in  this example }






That CA-chain is from the trust CAcert that we delivered and imported into our browsers.






Now that I'm off the  pcgus network, that chain is misleading since I'm going to the website
https://forum.fortinet.com directly. Until we tell firefox to clear it's self , that chain is misleading to the unaware , unsuspecting end user.

 




Now look at the  chain once we reload the website. Notice how the previous aus-webgateway.pcgus.com is now eliminated? And the real CA-chain is presented?






So always us a tool like curl or gnutls-cli when you wan to double or triple check the CA-chain for a website.

Or

Run the website thru  a site like SSLlab and inspect the chain.







 Doing this,  is a 100% sure way to determine if a MiTM device is doing inspections.If you see a CA-chain that does not reflect  the true raw chain from a site inspection-too, than you know that a "imposter" is in  the CA-chain .




Ken Felix





NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
     ^      ^
=(  @  @ )=
         o 
        /  \

FortiClient Trouble-Shooting IPSEC-vpn

The forticlient  logging  capability is great for major  diagnostics,  but some time you only need to following the window diagnostic output to guide you to a potential problem.

If you have a FortiClient  deployment and a few clients with problems , use the  feedback-windows or lack of.


1st up a bad Pre-Shard-Key



That should  need no explanation outside of  re-key your PSK


Next bad logins;



Here it's tricky

1: a bad  group-id
2: a bad username
3: or a bad password

Always validate the  users is  correct


Image result for TIP A group defined in the  client and  fortigate but the user is NOT part of that  group is also cause of bad login.



Let's say you have a   VPN- peer-id set and authserver group  and the actual vpn-user is not part of the group , the fortigate will provide the generic bad-login





 If you still have issues you might need to run fortigate cli diag debug cmds


e.g


diag debug enable
diag debug application ike -1





Image result for TIPUs the  diag vpn ike filter and on the client_address that's trying to connect in  a heavy used forticlient deployment


Lastly, if a client  tries to connect to a fortigate and have no pop-up windows this is a good indication of one or more of the following

1: client didn't reach the fortigate
2: client ike proposal where not matched and accepted
3: NAT or NAT-T issues
4: client had the wrong address  configued ( see #1 above )
5: or a combination of the above


 Ken Felix




NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
     ^      ^
=(  @  @ )=
         o 
        /  \