Looking at F5 APM VPN resources disconnects

Looking at  a new F5 vpn solution I found  it strange that you could establish a vpn and disconnect your virtual adapter and  reconnect without being  challenge at the start of the APM policy

Take a look at this  client  starting and stopping his  tunnel  numerous times.



Each new "start" does NOT challenge the user to  establish a new session from  the APM policy standpoint.

So keep  this is in-mind you have ClientSides checks and the users machine is no longer in policy you could open up a door into your systems with out of compliance   hosts.

In this APM policy we have the CSC  "continuous" checks disable due to other issues we found.





SO I'm not 100% sure if this would be a major issues to be concern with if you have continuous hosts checks enabled.

Ken
 

NSE ( network security expert) and Route/Switching Engineer

kfelix  -----a----t---- socpuppets ---dot---com

     ^      ^

=(  @  @ )=

         o 

        /  \

redirection loops http

I can't even begin to describe the number of times "  I've see HTTP 30X redirections loops from  poor  web-service hosting practices"

Think of a loop like that of this poor creature running in the circular cage

In most browser they will give up  a simple fatal error after XXX amount of loops-tries.

Various browser handle loops differently  but they always clearly  tell you a loop exists.


e.g  ( opera and safari )

cUrl will quickly show you redirect loops by using a the verbose output and  grep'ing for "Location:" header. If you see the same  Location: header more than 1 once for a http.get, than you have a loop condition.


e.g





It critical to test http.redirect and ensure you don't write a loop or create redirection dependency.

Ken  Felix

NSE ( network security expert) and Route/Switching Engineer

kfelix  -----a----t---- socpuppets ---dot---com

     ^      ^

=(  @  @ )=

         o 

        /  \

IronWIFI for fortigate admin authentication

In this post we will look at the RADIUS-aaS  using IronWifi.

https://www.ironwifi.com/

IRONWifi was designed around the support for a cloud based Wifi authentication systems . It works great and is used by numerous  guest and hotels based WIFI solutions &  that needs to authentication users.

Here I will demo a straight configuration using a IronWIFI radius-server for  a fortigate user.

On IronWIFI you will need a portal account in order to select a radius server region and create the RADIUS_users.  The offer demo  access and pricing solutions that will meet most ORGs needs.

They will provide a specific RADIUS-server port  for the auth/acct function which are not the well known radius services udp1812/1813 . The pricing  model of IronWiFi makes it economical if you need to support array of APs and numerous users. We  are going to use it for a fortigate-firewall &  for a local defined system admin user in this case kfelix.

Here's the cfg on the fortigate, it's identical to any other radius user cfg, btw.


You will need the  IronWiFi RADIUS_SERVER DETAILS to  complete the  fortigate configurations






Once you have an account setup, the cfg is simple for the IronWIFI items.





You can uncover the  secret 







RadiusClient




Users accounts creations





You have a simple dashboard , and its provides very good details for the avg administrator and on what's happen  (  when/what/who/etc....)





You have a host of pre-defined reports that can be executed to  displau access-accept or rejects. These  logs can be downloaded as a text-format  which will meet most audit-trails.



The meer fact that you can download  logs is a big plus imho and these logs are simple to follow.










The advantage of IronWiFi over jumpcloud RADIUS-aaS are listed here & along with a typical deployment design.

Both are gear as RADIUS-aaS services but they are different in many way. IronWIFI an JumpCloud are reliable and good solutions.

AFAIK,

IronWIFI does not have a LDAP-aaS  other contender in this market are foxpass.



 ironwifi supports chap and mschap so your 100% secure from prying eyes from a internet standpoint




Ken Felix

Ken Felix

NSE ( network security expert) and Route/Switching Engineer

kfelix  -----a----t---- socpuppets ---dot---com

     ^      ^

=(  @  @ )=

         o 

        /  \

finding traffic coming into a f5 that being dropped

Here's a sure way to find and log traffic coming into a f5 that has no  VS defined. It requires only a 0.0.0.0:0 VIP with a iRule to log the traffic



1st here's a layer3 forwarding VIP





2nd our iRule that we will use to generate a log message.I broke it into 3  iRules  IP TCP UDP





3rd our   log message when traffic actually hits the VIP and triggers the log-event






 I did   client add but you could also have done or add server_connect  but in this  case we wanted to see what traffic is coming in from where as in the client.


  you can be specific if you wanted to  trap and log a particular source


e.g

if { [IP::addr [IP::client_addr] equals 192.0.1.0/24] } {   

       log local0. "client   hit this VIP "                                                                             

    }

Ken

NSE ( network security expert) and Route/Switching Engineer

kfelix  -----a----t---- socpuppets ---dot---com

     ^      ^

=(  @  @ )=

         o 

        /  \

CAcert expiration notices

The CA known as CAcert provides certificate expiration notices that are easy and simple to follow. Here's  notice sent that shows various details

cert SN#
CN
etc...





They are a free CA but for the most part not trusted by any well-known  OSes. Where they shine at ;

• if you have a low experienced  CA team, CAcert could help with certificate signing for self-sign certificate
• Great for lab and testing 
• Great for  understanding the CSR and the  resulting Certificates that's generated
• simple interface  for cert-management
• great for POC ( proof-of-concept )
• great for budget  users that just need any ole certificate ;)

https://en.wikipedia.org/wiki/CAcert.org


Ken.Felix

Ken Felix

NSE ( network security expert) and Route/Switching Engineer

kfelix  -----a----t---- socpuppets ---dot---com

     ^      ^

=(  @  @ )=

         o 

        /  \

 

Securing Fortigate SSLVPN with MFA by using Duo and JumpCloud

In this blog I will demo a simple deployment for MFA & with fortigate SSLVPN service.

MFA  means "Multi Factor Authentication"

The general  fortinet community has been mislead to believe that you need a overprice forti-authenticator and a fortitokens solutions which does work & works good btw,   but comes at a higher price from a CAPEX.


Pls  refer to my  previous   post on fortitoken and Macosx and how the fortitoken works.
http://socpuppet.blogspot.com/2016/01/fortitoken-app-and-macosx-10111.html


$$$  Fortitoken are about on part with Duo cost per-seat and others. $$$ But   the fortitoken approach can not be used to  MFA other applications. Duo can be used from anything from  Citrix , Mail, VPn, DropBox and other systems. They look at each "service" as securing an "application"



So within both  DuoSecurity and JumpCloud,  we will use  MFA for simple 1st-factor &  2nd-factor authentication. The 1st factor is strictly ALL  JumpCloud, &  by using the RADIUS-aaS service.

The 2nd factor is via the Duo Push notification services &  to a registered end-user .  They both rely on the Duo-RADIUS-PROXY application.


From the end-user he/she will need  a mobile device and the Duo IOS/Android app installed on a mobile phone and actively enrolled.

I believe blackberry is not supported at this time


So the enrollment process is  very simple,  the  Duo Admin will craft a user in the DuoPortal. You only need the username and email address of the end-users. They  have the means for a bulk deployment if you have quite a few users to enroll at one give time.

A default or custom  enrollment email will be sent to the user via email and after a few quick checks and picture of a QRcode you will be enrolled and active.


This follow inline with almost all other TOTP  solution from  Goog-Authenticator , YubiKey, EntrustIdGuard,Solidpass, Authy, etc..... So I'm not going to go into details on enrollment.

Once you have user(s) in Duo that's activated,  each user could be tied to groups and policies based on that "application", this key since you can grant   unique access requirements and policies.

userA  VPN  & CITRIX access  secured MFA
userB  VPN-only  via MFA
userC  VPN & Citrix  & DropBox &  SystemAccess  via MFA
userD  VPN & RDP acces via MFA

 Think of  securing each applications uniquely,  and for that specific user or  user-groups.

Now when you 1st setup Duo,   your DUO admin access will be challenge every time and you can select the identification methods / Push / Text Call


e.g ( DUO admin   access )

Within the  portal you will toggle down and craft your Duo users as required and  the system with send the default or custom enrollment  email that  explains that  the user he is pending a enrollment in companyXYZ MFA solution.


e.g ( here's user:socpuppets being setup for enrollment  , take note of the SSLVPN group I've craft earlier, I will explain that later )

NOTE: I didn't want to  go into many details on  user enrollment that process is simple and mean video/kb exist from Duo and others on enrollment. If you can't manage a simple enrollment-process everything else here would be to complex for you ;)




Now that we have went briefly over enrollment process let's look at the key  Duo items that we will need  for configuration of the  Duo-Radius-Proxy on our windows or linux  host. I will demo the RADIUS cfg  file for a DEBIAN based host running in GOOG CLOUD COMPUTE

1st let's  review our topology;

  in google  at my  GCPinstance  I  had port  udp:1812 tied to another radius applicaton ( FREERADIUS ) so I choose a new port# just  for  the  Duo-RADIUS-PROXY udp:1822


The fortliclient  users will be authenticate,  by the fortigate  during the SSLVPN connection and based on the RADIUS-Accept/Reject will  gain access.

So the deployment steps are simple

1: gather your Duo Portal API details ( available  in your  portal login for the admin )

2: configure the GCP debian host for Duo RADIUS PROXY

3: gather your jumpCloud  RADIUS-aaS details ( ipv4 address, secret ,etc......)

4: hook all of it together

5: start the  Duo RADIUS-PROXY and  be happy ;)

So if you paid  any attention in  the Duo Admin setup you where presented a screen with these details
similar to the following;

These  informational pieces are  very critical you will the need the iKEY and SEC-KEY and target later on for any firewall rules. So save this information off  somewhere you can always review it late via the admin access and the DuoPortal.



On the fortigate it's simple but you need a radius server configuration. The Server will be the actual  device you have the  RADIUS_PROXY configured on. It could be local or in the cloud , but the device  must have a secret_define and RADIUS_PORT# . I ve covered this in previous recent post and  fortinet has cookbooks out for  how to configure radius-auth

http://socpuppet.blogspot.com/2015/10/fortigate-radius-observations.html


e.g





   I'm using not-wellKnownPort # of udp:1822 for RADIUS-AUTH in this example. The secrete I defined here would be the same RADIUS secret we will use on the DuoRADIUS_PROXY_CFG

DO NOT CONFUSE THE  RADIUS PROXY and the JumpCloud RADIUS-aaS configuration. Think of the  DuoProxy as front-end and the JumpCloud is the backend. The fortigate device will TALK to the  Duo on the front-end and  Duo talks to JumpCloud on the backend.


Now we will setup the Duo-RADIUS-proxy server we will stroke this in the cloud.

The duo-proxy setup can be follow from a simple  HOWTO that's available on Duo website
https://duo.com/docs/authproxy_reference

My cfg looked  similar to the following  on my debian instance

  I redacted critical details from this screenshot



After you have the  instance  up,  you can plumb firewall rules in GCP to allow traffic to the RADIUS_PROXY.

By using tcpdump , you can diagnose  fortigates ( clients )  that are not able  to AUTHENTICATE to RADIUS_PROXY.


sample  fw_rule

GCP firewall  with udp:1822 set




Okay now that you have all this configured,   you can  validate function by authenticating a user from  the  fortigate. If all was correctly configured & working;

FORTIGATE ( radius client )
DuoRADIUS_PROXY
JumpCloud_RADIUS-aaS

Than the end users that's enrolled and part of the Duo SSLVPNGroup would get a challenge in the fashion of a push to his/her  mobile device that  they used to enroll.



Here you can  Accept or Deny via a simple push notification ( no 6 digit passcode )

  Duo allows you to craft "specific text for  the push message" so you  know what your accepting. Most other systems just blindly send you a  notification but for what application, is never known. This is helpful if you use Duo to secure multiple  application and what a custom notification message for each application.

Now groups,

Groups in Duo is the key to all things. For  the SSLVPN fortigate you can have many groups allow users in just that group. These groups could be inherit into Duo for simplistic matching.  So group at the company fortigate(s) could tie back to the same group in  DuoSecurity.

In this demo, I have a group name   sslvpn for the fortigate SSLVPN solution.






Let's explore some reporting & logs ;

locally the  radiusproxy logs are stored at the directory on my linux instance;

/opt/duoauthproxy/log/

It provides MFA related messages for 1st and 2nd factor. Here's example of "chap" login failure from the radius_client and latter  a pap login request that was successful.




From  fail_auth you can get lockout alerts and run reports from DuoSecurity portal. One cool thing on lockouts, you can lockout and require MFA-admins to re-active

Or

Set lockdown thresholds and holdout,  and after the holdout timer has expired, the account will be re-activated automatically








e.g










Authentication logs within the DuoSecurity portal are very detail and helpful in  determining if a request ever made it to Duo and by what applications.

e.g  ( csv log-format )





e.g  ( json format  user enrollment )




So within  the Duo portal you can determine with ease the  success and failures , and enrollment status for a user. So that's all that it takes.

Enjoy  Duo  and  JumpCloud for your SSLVPN fortigate solutions that need MFA.

Meep .........Meep, I got to run.

Ken Felix
Security Engineer

NSE ( network security expert) and Route/Switching Engineer

kfelix  -----a----t---- socpuppets ---dot---com

     ^      ^

=(  @  @ )=

         o 

        /  \