SNI checks for F5 VirtualServers

Using SNI ( server name indicator )  for a virtual-server in a host web environment that requires  TLS connections , is not un-heard feature.


The combined use of layer7 host header and SNI allows for one single address to host dozens or hundred of websites. To learn more about SNI review here.

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

A quick means for testing  support  for SNI support or no-SNI ,  is to use the common  GNUtls utility gnutls-cli without or with the --disable-extensions option.

Check out a Virtual-Server that was enabled for support in the client-side-ssl profile;

In this case my way port wifi provider intercepted my request for www.wwt.com, here's a direct request to the same size without and with SNI in the initial client-ssl hello.

If you happen to  initiate a ssl-session with the SNI extension disable the end-node does not support SNI & the clientssl profile defined for the default SNI is incorrectly set for "required", you will get a  ssl fatal error.

Ken

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

     ^      ^
=(  @  @ )=
         o 
        /  \

F5 self address and the floater confusion

Confusion always comes up with a self address types. You typically have  a "real assigned" ipv4-address per-interface

A floater is another type of address that's "floats ( hence the word  floater ) between the active  F5 in a cluster

The reasons for the floater is required   for "inline" function where the clients or servers are routed using the  floater as a next-hop.

The other advantage for the floater is for the  determine which unit is actually active ( you can ssh and/or  HTTPS  ) and see the hostname of the  of the active unit

It's can also not be used for any configsync operations

And finally the floater address does offer any  http health checks or  even in-use for client-side SNAT.


Ken

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

     ^      ^
=(  @  @ )=
         o 
        /  \

Fortigate HA link uses telnet ( no-ENC )

When setting up a  HA link you need to be aware that with out  the encryption enabled, your HA traffic is in the clear.

What this means, anybody who creative can sniff traffic and gather  information. Here's what the cli cmd  diag sniffer packet port_ha "port 23"  shows

 You would think a security outfit would never use  telnet 

Enabling encryption for the  ha configuration is a must & is available from the CLI only.

Ken

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

     ^      ^
=(  @  @ )=
         o 
        /  \

FQDN address policies fortigate FortiOS

I was using a  FQDN policy object in a firewall and want to share some simple tips that could come in handy. To review if the  FQDN is mapped & found,  you can use the following  cli command

    diag firewall  fqdn  list 

To purge ALL objects the following cli cmd

    diag firewall  purge

To set  specific TTL for caching, set the  TTL in the object  directly.

e.g

config firewall address
    edit  dns1
         set type fqdn
         set fqdn www.example.com 
         set cache-ttl 10
   end

In the above, "The firewall will conduct a  DNS lookup and refresh the local-cache ever 10secs if it has changed.

If the objects has multiple A records, it will  display all records attached;

FGT310C (root) # diag firewall  fqdn  list | grep www.etrade.com
www.etrade.com: ID(117) REF(1) ADDR(65.196.177.42) ADDR(12.221.217.42)
 
FGT310C (root) # diag firewall  fqdn  list | grep www.twitter.com
www.twitter.com: ID(19) REF(1) ADDR(199.59.149.198) ADDR(199.59.148.82) ADDR(199.59.150.7) ADDR(199.59.148.10)




A firewall object of type fqdn will use the   firewall local dns-servers settings to resolved the  FQDN.

 A FGT firewall will ALWAYS resolve a FQDN object regardless if it used in a firewall-policy 


A fqdn firewall address object that does NOT exist, will still be cached but with no  resolved address;

   diag firewall  fqdn  list
   List all FQDN:
   nohost.socpuppets.com: ID(140) REF(1)

be carefull  of bad FQDNs or no-such hosts, traffic will be blocked.




The firewall fqdn firewall-objects are ONLY applicable for ipv4 address, hosts with both A and AAAA resources will only display the A record. You can't do  fqdn type in address6

I haven't checked in FortiOS 5.4 to see if this feature has change




Ken

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

     ^      ^
=(  @  @ )=
         o 
        /  \

Fortianalyzer 5.4.x issues

Since launching the  VM -FAZ appliance and upgrades , we still see various issues;

1: chartviewer fails
2: working reports fails to display
3: unable to launch the console ICONs " Failed to Start"

The item#3 is a new one that requires a reboot. I didn't bother opening a ticket with FTNT  btw they have been just about useless imho

I hope the next release of FAZ fixes these issues.

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

     ^      ^
=(  @  @ )=
         o 
        /  \

The SSL certificate has nothing todo with the ciphersuite strength

Most individuals installing a HTTPS  web site seems to think the "certificate" or the CA controls the  cipher suite strength which in fact is 100% wrong.

Take a  SSLLAB analysis of a website that was recently installed.

All of the  weak ciphers in the above list scored this site as marginal B score. But have no fear, socpuppets is here.

You can enable only strong ciphersuites and retest the site using SSLLAB and witness the new grade.

( after striking RC4 MD5,etc......)

Now the site has a A+ grade and it's still the same server and installed certificate+private-key.

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

     ^      ^
=(  @  @ )=
         o 
        /  \

Using Execute log filters to monitor firewall traffic

One cool function that's over looked in the firewall ( fortigate )

1: if you have logtraffic all enable on your firewall policies, you  can construct filters for traffic flows

2: and display just  traffic that has hit the define category and filter field(s)

3: speed up "traffic review" without  having to go to a remote logging appliance
  (  forticloud, FortiAnalyzer  remote-syslog )


Here's a simple example using just a policyid and the with the traffic category { # 0 }

Now if a match was found, we would have details similar to the below;

Here's a few of the filters that available under category #0 { traffic }

FWF50D (socpuppy) $ execute  log  filter  field 
Available fields:
timestamp
action
app
appact
appcat
appid
applist
apprisk
collectedemail
countapp
countav
countdlp
countemail
countips
countweb
craction
crlevel
crscore
custom
date
devid
devtype
dstcountry
dstintf
dstip
dstname
dstport
dstssid
dstuuid
duration
group
lanin
lanout
level
logid
mastersrcmac
msg
osname
osversion
policyid
poluuid
proto
rcvdbyte
rcvdpkt
sentbyte
sentpkt
service
sessionid
shaperdroprcvdbyte
shaperdropsentbyte
shaperperipdropbyte
shaperperipname
shaperrcvdname
shapersentname
srccountry
srcintf
srcip
srcmac
srcname
srcport
srcssid
srcuuid
subtype
time
trandisp
tranip
tranport
transip
transport
type
unauthuser
unauthusersource
user
utmaction
vd
vpn
vpntype
wanin
wanoptapptype
wanout


I find myself using the following options the most;

    dstip,srcip,policyid

Btw these are the same filters available in the FortiAnalyzer.

By using a string of filters you can easy obtain if traffic is matching and the action taken.


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

     ^      ^
=(  @  @ )=
         o 
        /  \

fortinet thruput numbers be aware

If your not performing your own benchmark tests, than you have to rely on FTNT or a 3rd party  like NSSlab.


Most numbers give in a product sheet are not  100% real-life but a good assumption  on FTNT behalf. The thruput numbers will be greatly impact by the number of session , session setup, type of data and protocol and packet-sizes. Lastly, you need to be aware of the various feature from a UTM standpoint.



So how do we get real life thru-put numbers ?


That question has no  real  answers since in some case real-numbers are secretly held or test data is not made public.

NSSLab is a go to for most "real numbers"

2nd would be "word of mouth from  real end users "

Trust nothing,  until you can validate 

That's  my  final   answer !

With any product data-sheet, I like to reduce the  list number by 10/20% as a margin. So if you have a requirement of XYZ and the model of the unit is near the 10/20% value, jump to the next larger device.

Ken Felix

NSE ( network security expert) and Route/Switching Engineer

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

     ^      ^

=(  @  @ )=

         o 

        /  \