Tuesday, October 25, 2016

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

     ^      ^
=(  @  @ )=
        /  \

Monday, October 24, 2016

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;


mac-1093e90f35a4:~ kfelix$ gnutls-cli | 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

     ^      ^
=(  @  @ )=

        /  \

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 .


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.


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

     ^      ^
=(  @  @ )=
        /  \

Friday, October 14, 2016

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 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
        set psksecret  mysecrethereissogood


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


Notice I'm using  a quad 0s for the src/dst-subnets aka 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 



config router static
   edit 1999
        set dst
        set device "GCP"
        set comment " my tunnel to GCP platform"


  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 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 )

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

5: monitor the vpn and bgp outputs


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, 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     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
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
*>            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

     ^      ^
=(  @  @ )=

        /  \

Wednesday, October 12, 2016

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.



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


 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

     ^      ^
=(  @  @ )=

        /  \

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.


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


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


NSE Network Security Engineer
{  Fortigate,  PaloAlto ,  CiscoASA }

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

        /  \

Thursday, October 6, 2016

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 )


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