detrming fortiOS uptime

In the fortigate firewall  you have a  few creative ways for determining the system uptime without accessing the  webgui


1:  by using the hidden  cli cmd  fnsysctl cat /proc/uptime

requires you to convert  seconds to  Month/Week/Days


2: execution of the diag sys top command and looking at the  system runtime


Ken

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

     ^      ^
=(  @  @ )=
         o 
        /  \

A quick and sure to know if a SSL certificate is a used as a CertAuthority

Under the x509 v3 we have special attributes  for indicating the purpose of a certificate and if it's "CA".

By using the openssl x509  we can review what's the certificate  type and if it's a CA certificate.


Take this certificate  chain where we have  two certificats  and we want to find out which one is a CA certificate from a  usage standpoint




Notice the CA: TRUE vrs the CA:FALSE if the former is set, then that's a indication it top of the chain and as  a rootCA  or intermediate certificate.

Take this Entrust Chain where we have a root, plus 2 intermediate certificates and finally the server

( I'm showing the  CA: flags for the root and intermediates outputs  truncated  )


















( now at the end of the  chain we have the server certificate, notice the CA:FALSE )







So you have a few means for validate the certificate and it's usage.

Ken

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

     ^      ^
=(  @  @ )=
         o 
        /  \

Fortianalyzer webgui access issues

The Fortinet Analyzer is a log-event collector and analyzer that allows for generating and monitoring for system related activities such as;

     traffic reports
     ipsec/ssl vpn reports
     admin & configuration reports
     system related event 
     log retentions


When it ( FAZ )  works,  it works great. When it give you problems it can become a big headache.  Here's a big problem under FAZ 5.4.1 that has came up now a few times.

1: symptoms; " you can login into the WebGUI,  but the GUI does not work"

2: ssh cli access seems okay btw


screenshots








Okay nothing from the dig sys process show anything out of the ordinary. But upon a simple execute backup, we found the  filesystem read-only and the backup files.





So it looks like faze5.4.x OS is not reliable in a virtual appliance. So to get this appliance back up for  service,  we had to execute reboot from the cli.

After a reboot the unit is able to be backup and webgui access works.






Ken Felix

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

     ^      ^
=(  @  @ )=
         o 

        /  \

The webportal under 5.4.

Looking at  the web portal  in fortiOS v5.4.,  shows the site layout is now plain and simple




Very simple , not complex , and  very neat .

Ken Felix

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

     ^      ^
=(  @  @ )=
         o 
        /  \

cisco ACS local-server

With the cisco ACS appliance  the local certificate is issued at  1year. If it should expire you can easily craft a new certificate that's self-signed or a CSR.

The steps are very simple under ;


System Administration > Configuration>  Local Server Certificates

1: Select the  certificate type with the correct CN/lifetime

2: ensure  you set the  new certificate to  be use for  EAP and webGui


3: issue a acs stop and a acs restart  after deleting the pre-existing local-server-certificate


4: confirm the new certificate is indeed being used;

e.g

mac-1093e90f35a4:~ kfelix$ gnutls-cli 10.50.2.241 | grep expires
*** Fatal error: Error in the certificate.
*** Handshake has failed
GnuTLS error: Error in the certificate.
 - subject `CN=WTW1INFPVTAC001', issuer `CN=WTW1INFPVTAC001', RSA key 2048 bits, signed using RSA-SHA256, activated `2016-10-11 19:02:25 UTC', expires `2019-10-11 19:02:25 UTC', SHA-1 fingerprint `5a6018dbf4ae42b22e99b449aa539e767d8af6eb'
mac-1093e90f35a4:~ kfelix$



Ken Felix

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

     ^      ^
=(  @  @ )=
         o 

        /  \

PANOS product security vulnerabilities a new approach

PaloAlto sent me a email a few days ago that was quite interesting. They  are  publishing a list of  recent product  security advisories .

(e.g)




The link  also directs you to the  web site that list numerous  issues and the PANOS versions.  These post are rate to  the current  severity and a brief summary.





The also have a product submittal link for if you should find issues. The submittal is quite simple.


https://securityadvisories.paloaltonetworks.com/Report

So it seems like Palo Alto is taking end-user feedback and for issues found , very  seriously.

Ken Felix

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

     ^      ^
=(  @  @ )=
         o 

        /  \

GoogleCloudCompute VPN to fortgate

In this post I will show you how to craft a vpn for  a Fortigate to Google Cloud Compute Platform

The process is straight forward;

1: you need to select a Google ipv4 static address for the vpn-peers, This is the  public-address that you will use and defined for the remote-gate on the fortigate

2: define ikev2 ( you can use ikev1 )

3: define a shared PreSharedKey ( watch for any  typos and the psk key lengths   12-20 characters is good , try to avoid whitespaces or *!# )


4: define the local and remote subnets ( or use the 0.0.0.0/0 in the quick selectors )

Once you have done all of the above, you  can configure the  fortigate unit;


Phase1-interface cfg
( take note of my  single proposal & dhgrp14 )

FGT100D (root) # show vpn  ipsec phase1-interface 

config vpn ipsec phase1-interface

    edit "GCP"

        set interface "wan1"

        set ike-version 2

        set proposal aes256-sha1

        set dhgrp 14

        set remote-gw 130.211.107.192

        set psksecret  mysecrethereissogood

    next

end

Phase2-interface cfg
( take note of my  single proposal & dhgrp14 , and pfs is enabled by default )

FGT100D (mycust1) # show vpn  ipsec phase2-interface

config vpn ipsec phase2-interface

    edit "GCP1"

        set phase1name "GCP"

        set proposal aes256-sha1

        set dhgrp 14

        set auto-negotiate enable

    next

end

Notice I'm using  a quad 0s for the src/dst-subnets aka 0.0.0.0/0:0 in the above example

Here's a few screenshots of a typical  GCP vpn configurations. It's so easy a caveman can do it !

The last piece you need are routes-and- firewall policies on both ends 

google

Fortigate 

config router static

   edit 1999

        set dst 10.240.0.0 255.255.0.0

        set device "GCP"

        set comment " my tunnel to GCP platform"

    next

end

tips;

1. use ikev2 for IKSAMP
2. ensure dh-grp 14 only
3. set propsoal for aes256-sha1
4. set pfs enable
5. ensure you know what interfaces you have in-use at Google Compute

For diagnostic, use the GCP  log view and with the filter for  ipsec.events. Look for the obvious problems or errors.

 PSK mis-match

 no acceptable-proposals between peers

 no acceptable  SA src/dst-subnets ( if you specify src/dst-subnets and not 0.0.0./0 ...THEY HAVE TO MATCH )

 be very very very careful of route priority if you use  0.0.0.0/0 as the proxy-id selectors set the priority   for traffic you want to go over the tunnel

A bad PSK match

A good up and working VPN  GCP  will look like the following and with a green-icon "check" mark.

!!!!!!!!!!!!!!! ADVANCE  BGP over IPSEC   for layer3 network routing  !!!!!!

You can also run BGP over the ipsec-tunnel  for routing information to be shared.  This is the same method that  AWS uses btw and the fortigate is way much easier to configure for this approach versus other firewall vendors.


This steps are broken-down  as the following;

1: define a cloud base router instance-name

2: select a private ASN for GOOGLE and your Fortigate  (e.g ASN 65001 )

3: use a link-local ipv4 address for the Google  and Fortigate End Points ( APIPA  169.254.0.0/16 )


4:  configure the  fortigate using the private-AS for the local and remote-as peer

5: monitor the vpn and bgp outputs


screenshots

google cloud platform  BGP config

FGT-2-GCP configurations

The fortigate BGP configuration will require you to  assign a ipv4 address on the ipsec-tunnel interface directly &  with the local-remote address of the Google cloud router instance

Now you can use any  of the FortIOS  get  commands to get bgp information. Just remember the ipsec-vpn must be up before the BGP can go established and peering relations started



For Example;

FGT100D (root) # get router  info bgp summary 
BGP router identifier 169.254.0.2, local AS number 65102
BGP table version is 1
1 BGP AS-PATH entries
0 BGP community entries

Neighbor        V         AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
169.254.0.1     4      65100      12      12        0    0    0 00:03:07        1

Total number of neighbors 1

 
FGT100D (root) # get router  info bgp network
BGP table version is 1, local router ID is 169.254.0.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.240.0.0/16    169.254.0.1            100             0 65100 ?

Total number of prefixes 1


 ( other useful get-commands )

get router  info bgp neighbors

get router info routing bgp

   

Ken Felix

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

     ^      ^
=(  @  @ )=
         o 

        /  \

HOWTO determine QUIC support by inspecting http.response headers

To go along with testing QUIC support in the past blog post, in either   firefox or chrome browsers and websites that supports QUIC connections, they all  will  provide notice of support for this protocol in  it's  http.response headers.


examples;


firefox-browsers

notice spdy ( speedy support ) is also in the response header




chrome-browsers

 If you  want to disable QUIC and SDY from a client, use a proxy and drop  these headers from the response

Ken Felix

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

     ^      ^
=(  @  @ )=
         o 

        /  \

How to force QUIC connections with Google Chrome for testing

My day job is  panic'ing  over QUIC udp  connections & with  our proxy. QUIC is not new but most network/security engineer don't understand it muchless know how to test for access w/QUIC.


Here's a simple way to force a  QUIC connection  & to test if your Chrome browser has support  for QUIC connections to a website and  if your firewall and proxy support  QUIC.


1>

from the cli ( macOSX  in my  case ) , we set the  quick enable and the  server  name:port that we are connecting to;

example  cli command open launching chrome

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome   --enable-quic --origin-to-force-quic-on<sitename:port#:80>  http://<sitename>

2> Now you can monitor these from the chrome browser using the chrome integral URL for quic connections



insert the following in a new window tab

  notice the above connections where over my t-mobile  ipv6  hotspot cool ;)





This is a sure way to enable QUIC connection and to monitor them. If the  site is not available for QUIC you will get the classic quic connection error in your browser indicating the protocol


e.g





You can also inspect TLS over QUIC via the  "https" icon  if you  want to inspect  SSL/TLS and QUIC support or use  tshark.

( https over up  port 443 )

notice udp as the transport




If SSL/TLS support is not supported or fails, you  unix shell will display the following output upon launching




Ken


NSE Network Security Engineer
{  Fortigate,  PaloAlto ,  CiscoASA }

kfelix   a...t   socpuppets.com
     ^      ^
=(  @  @ )=
         o 

        /  \

howto block fortigateOS admin account access

In this quick post I will show you a 1 2 3  step in  blocking the admin account. As you probably know the admin account is a factory account named in the FortiOS

1: you can delete it from config sys admin

2:  if you remove it out of a  fortiOS config and retore that cfg,  the firewall will still re apply it.


It's like a bad rash that won't go away.

To make admin in operative you and to satisfy any security concern you need to hack it. The process is simple.


Define a noaccess profile
apply admin to the noaccess profile
set a password value of  more than 32characters ( beadvise fortiOS has a password max value length )

e.g

TIP:  if paranoid







next , define a  two-factor with a email address that's not valid 


And finally apply trusthost statements for that account to a non-used and routed address. The finally configuration would  something like this.


system admin  access profile with NONE

the account admin lockdown

Ken