Wednesday, June 21, 2017

Defining multiple sites with unique TLS protocol on f5 for compliance with TLS

Take a typical  websites hosted on a F5-LTM that using  a wildcard and SNI.


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


www websites 1 2 3

www1.example.com
www2.example.com
www3.example.com



So let's say that www1 needs to support TLS1.2 only and  www2 and ww3 can support any of the other TLS version. The virtual_server is using   one wildcard.cert for *.example.com.


How can you achieve this ?  .............The answer is quite simple!


In the F5 client-side profile you will to replicate  3  client-side profile and defined the server_name in the profile.

And within that profile you can enable or disable the  various SSL/TLS version from  Negotiation between the Virtual-Server and client.


So in the end you will have  2 or 3 profiles

1: one for  TLSv1.2 -only and  www1.example.com for the server_name
2: one for  www2.example.com and www3.example.com with the  server_name and all TLSv1.x
3: or just one more  as *.example.com and no server_name defined


Take a look at these client_side profiles

Local Traffc > Profile  >  SSL client  www1.example.com

Local Traffc > Profile  >  SSL client  www2.example.com and www3.example.com


 Than just test using curl and select the TLS version.

e.g


curl --tlsv1.0 https://www1.example.com
curl --tlsv1.1 https://www1.example.com
curl --tlsv1.2 https://www1.example.com


and



curl --tlsv1.0 https://www2.example.com
curl --tlsv1.1 https://www2.example.com
curl --tlsv1.2 https://www2.example.com

and

curl --tlsv1.0 https://www3.example.com
curl --tlsv1.1 https://www3.example.com
curl --tlsv1.2 https://www3.example.com


Only the allowed and enable TLS version should established based on the  client_side ssl profile settings and the server_name entry


Ken



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


Tuesday, June 20, 2017

Finding windows XP/2003 winhosts using fortigate device ID

Fortigate has a simple OS device id function. You can easily enabled this on  any interfaces except

  • ssl 
  • vpn
  • vdom-link
  • loopbacks
  • etc....

To enable the device-identification you only need to  set the following on each interface that you want to  id;



config sys interface
     edit lan
           set device-identification enable
     end

And then wait for a few minutes before reviewing the  output of the detected devices.


FGT100D (root) # diag user device  os-summary
host operating systems discovered
  OS                   count
  unknown                  8
  Linux                    13
  NX-OS                    9 
  Cisco Catalyst L3 S      1
  Windows                 88


The  device id is simple to understand & follow.

e.g

( nexus switch  learned via  lldp )

   type 16 'Router/NAT Device'  src lldp  c 1  gen 4
    os 'NX-OS'  version ''  src lldp  id  36  c 1

 ( a linux host learned via tcp-fingerprint )

   vd root/0  00:00:ca:00:00:03  gen 13859  req 38  redir 0  last 0s  wan1
    ip 185.165.29.97
    type 6 'Linux PC'  src tcp  c 0  gen 6
    os 'Linux'  version '3.11'  src tcp  id  364  c 1

( a windows product  learned via IIS webservices)

   type 8 'Windows PC'  src http  c 1  gen 14
    os 'Windows'  version 'NT 10.0'  src http  id  1850  c 1

(  here's a user on mindsprings using pop3 unsecured  )
 c0:8c:60:b0:e7:00  gen 120009  req 0  redir 0  last 0s  Inside
    ip 10.5.5.55
    type 8 'Windows PC'  src http  c 1  gen 35
    os 'Windows'  version '7 (x64)'  src http  id  2168  c 1
    host 'CHO-0000002'  src mwbs
    user 'useronpop@mindspring.com'  src pop3

( unknown )

   00:01:d1:2d:12:43  gen 1501701  req 3c  redir 0  last 0s  DMZ
    ip 1.1.1.1
    os unknown  sig 'W mss 4;T 255;D 1;S 60;O m1440 s t n w7;'  src tcp


Now that you have understanding of what the device-id does,  you can now grep out for the strings of windowOS or the strings of interest.

e.g

 diag user device   list | grep  -i  "Windows"


Here's a  few windows  XP hosts that was located



And here's a  XP string





Now your security analyst   and IT team members  can target and  eliminate the non-compliance hosts.

Ken Felix



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

        /  \

Monday, June 19, 2017

Forticlient 5.6 MACOSX initial reviews

FTNT  has released forticlient 5.6. and the MACOSX  install and launch has been flawless for me. Here's some screenshots of the  FClient and the new scaning display








The  Forticlient  list the vulnerabilities  by  level and can help with correcting the  issues.


By opening the vulnerabilities you can review the list CVE  details and summary.




Ken   Felix



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

        /  \

Friday, June 16, 2017

MFA using certficates fortios sys admin

You can deploy  fortigate systems users for access the firewall by using  pki certificates. The advantages to this approach;

1: it supplies an  alternative approach for  MFA  ( username user.cert and optionally a password )
2: no need to roll out a big MFA token soultion
3: it allows you to restrict a user.cert and profile for system admin logins
4:  provides an option to lock down users from accessing a FGT to only just HTTPS but this still access via SSH for other users ( a PKI user can not access a fortigate via SSH )
5: works great if you have an existing PKI structure and have no restrictions for sign user.certificates
6: you could pre-sign  users certificates for a future date and duration and revoke users access



Here's the summary steps of the deployment for pki-users deployments fortigates.

1: upload the  CAroot for the user.certificates that will be sign ( very important the CAroot certificate(s) must be installed on the fortigates they will access )

note: you can have multiple CAroot-certificates install, but the root.certificate needs to be upload into the local fortigate CA storage. You might have  multiple CAs that signs various users certificates or foreign CAs that you most import as required.

see this diagram of a approach for Enterprise and Contractor or Vendor, where you have multiple CAs that issues  user.certificate for various roles , each users could have a unique  role ( access profile for that user )







2: sign  the user(s) certificates against the CAroot/key or have the user obtain a signed certificate.


3: issues certificates to  the system-admin users and profile and grant accessprofiles

4: The user needs to import the cert+key into it's OS user.certificate list , typically this is in a pkcs format ( macosx, windows, must browsers, etc....)

5: The fortigate need a user-peer defined with just at minimum the CAroot-CAcertificate selected and optionally you can apply the CN and SUBJ fields to that PKI user peer details to scrutinize  the user.certificates even more.

6: next you need need a user-group set for "firewall" with the pki peers added

7: finally you  set the  system-admin  user names  in the fortigate and set the define mode as peer-auth and the peer-group.




Here's a few snapshots of the above actions;



{ defining my pki details;
  cn with 2nd factor  password required ( optional  but advise ) }




You can also defined more grainular the subject details from the certificate also;



 TIP: use  openssl x509 and the -subject to find the subject details





{ peer-group }







{  cli cfg details for my user }













or


with IE select the correct certificate to present;



Now we login via the HTTPS webgui and present the certificate and 2nd factor password if applied and if you did everything correctly you should be logged in





Using this approach, you could give your  remote_contractors a user.certificate or have him supply his own certificate and you upload the CAroot for his user.certificate.issuer

If you control the user.certificate from your own CA signing structure, you could sign a user.certificate for duration XYZ , and never have to worry about restricting access a future date.

You could even sign a certificate for a future date and  duration, and pre-issue access for a set of users  and known that they can't access the systems until  the date is valid. This is great when working with outside consultants or technology partners that needs access for projects.

If a certificate is compromised you can pre-empt the access and revoke the certificate /remove the pki user/ or CAroot.crt  as an option.

 Try to  keep your own  certificate simple. You subject field could only contain a CN only

e.g







Use the cli cmd   debug application https -1  to troubleshoot the login process via WebGUI

 If the status response is "1" than you have successfully login via two-factor and with the certificate.





Ken Felix



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

        /  \

FORTIOS logging uuid

In fortios you have the options for logging UUIDs for firewall traffic . This is controlled by the global system setting

config sys global

 set log-uuid extend
 set log-uuid policy-only
 set log-uuid disable
end

 I'm going to demo the output differences based on the above settings.




Notice the differences in the output for log traffic?

The extended uuid logging populates the  extend UUIDs details,  and this will increase the size of the  log-data payload.



Ken Felix




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

        /  \

Wednesday, June 14, 2017

How to get in on Apple Root CA trust

Apple has  documented the  methods on  how you could be added to Apple's trusted CA root-lists

https://www.apple.com/certificateauthority/ca_program.html

The following link will  direct you to the process of how you could be added to apple  root CA list.




You need to  email apple.pki  at the following address to  initiate the process

  You need to  email apple at the following address to  initiate the process
certificate-authority-program@apple.com


Apple own PKI listing & posture is well documented here;

https://www.apple.com/certificateauthority/


 Ken Felix




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

        /  \

Monday, June 12, 2017

Client Auth Issues for Mutual SSL/TLS

Within   TLS we can   authenticate the "client". This is called mutual authentication. The client authenticates the server and the server the client.

In this post we I explain some common issues to look at when mutual authentication does not work





1st,  the certificate used by  the server needs to validate.

2nd, the client  certificate needs to validate. This also means it can be older than the expiration or yet activate

i.e F5 debug log for a non validate user-certificate


3rd, the client certificate store typically only provides the user certificate if  item#1& #2 are true and the site  issues matches the certificate found in the user local store.



4th,  the web clients needs his/her certificate and matching key. This combination is what's used for the site. The web-server will extract the public-key from the x509 certificate when authenticating

5th,   a web-server might ignore a certificate if one is provided

Next, the  web-server  needs the CA to use for  verification. The  CA used for the client might NOT be the same one for the server-signed certificate.

TIPS:

1>

Client certificate either has a UPN { user principal name } or CN { common name }  field and this can be scrutinize a web-server when mutual authentication is required. Either one should be correct for the user and the applications and in  the correct format

i.e

kfelix
ken.felix
kenfelix@socpuppets.com
etc....


2>

If the server uses a CRL, ensure the client-certificate  is not revoked.

3>

If  the site support auth-fallback,  this will come into play after SSL mutual-authentication request.


4> In most cases, the client certificates does NOT need to signed under the same CAroot as the server. Most servers that use mutual TLS/SSL client-auth,  will let you set the CAchain for the client's certificates that are to be trusted & allowed.



by using curl you can validate and gather verbose details

i.e


curl -v --cert <pkcs format certificate+key>:passphrase  https://yourserver.yourdomain.com/


Review the curl output for further paths to  explore and investigate.








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

        /  \