In version 6.x FortiOS the filters in the fortivew monitor do not work. In fact, you see the geo flag for the destination but if you apply the country as a destination filter it never works
In 6.2.x these seem to be operating correctly;
So it looks like FortiOS v6.2.x has a few good fixes and improvements.
Saturday, December 28, 2019
Thursday, December 19, 2019
Forcepoint NGFW now has ICAP support
Finally, the NGFW can communicate with ICAP in version 6.7.0. Here are a few interesting observations from Forcepoint.
Like the lack of "WCCP" and support to its own web-proxy ( Websesene ) , it looks like the NGFW can be used with the Forcepoing own DLP solution.
NSE ( network security expert) and Route/Switching Engineer
Like the lack of "WCCP" and support to its own web-proxy ( Websesene ) , it looks like the NGFW can be used with the Forcepoing own DLP solution.
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
^ ^
=( @ @ )=
o
/ \
Wednesday, December 18, 2019
SRX upgrades and alt-partitions
Within junos and with the SRX you can upgrade the SRX and boot into that partition. This blog will show you some simple commands to validate the active partition and the code installed.
In most case, the junos has two partitions that hold the base-software. Only one of these partitions is active at any given time !
The above shows a junos disk layout. When you upgrade a junos device you are installing the software in the inactive partition. If you call the "reboot" with the request system software, this is a toggle that turns the newly upgraded partition on so to speak.
You can start a shell from the cli and review the active partition or partition that's set bootable on a SRX.
e.g
# done from a cli access within junos cli
start shell
su -
fdisk /dev/da0
Flag 80 == that slice is active on this bsd disk
Here's a screenshot of a recently upgraded SRX that was previously running D190 and now has been upgraded to D200
A quick and easy way to copy the installed junos version to the backup slice is to use "request system snapshot slice alternate"
e.g
and finally, we confirm with "show system media internal"
I hope these tips come in handy when you are doing maintenance on a juniper SRX.
NSE ( network security expert) and Route/Switching Engineer
In most case, the junos has two partitions that hold the base-software. Only one of these partitions is active at any given time !
slice { aka partition } da0s1a orda0s2a
The above shows a junos disk layout. When you upgrade a junos device you are installing the software in the inactive partition. If you call the "reboot" with the request system software, this is a toggle that turns the newly upgraded partition on so to speak.
You can start a shell from the cli and review the active partition or partition that's set bootable on a SRX.
e.g
# done from a cli access within junos cli
start shell
su -
fdisk /dev/da0
Flag 80 == that slice is active on this bsd disk
Here's a screenshot of a recently upgraded SRX that was previously running D190 and now has been upgraded to D200
A quick and easy way to copy the installed junos version to the backup slice is to use "request system snapshot slice alternate"
e.g
and finally, we confirm with "show system media internal"
I hope these tips come in handy when you are doing maintenance on a juniper SRX.
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
^ ^
=( @ @ )=
o
/ \
Tuesday, December 10, 2019
The zone firewalls rules ( juniper paloalto )
A very thinking with security zones is that security admins believe all interfaces in a zone are allowed by a policy rule if that zone is called up in a src/dst.
A rule that has the proper src/dst-address and src/dst-zones for the traffic pairing, will allow only that traffic flow that is listed in the address.
So take a zone with 10 interfaces and is called "trust", All 10 interfaces and network(s) behind them will NOT be automatically allowed by a rule unless you wrote it poorly by using "all or any".
( here's an example of zone named:trust with 5 interfaces )
( networks 192.168.{1..5}.0/24 }
So a rule written with src-address match and ALL will cover all 5 networks. But that would be a very bad rule unless that is what you really wanted.
A proper rule would have the specific subnets or hosts listed.
The proper rule authoring is a must if you want to be tight within the security policy. The use of "any" should be scrutinized very closely to ensure the proper security practices are being used.
This holds true regardless of the firewall model type or vendor.
NSE ( network security expert) and Route/Switching Engineer
A rule that has the proper src/dst-address and src/dst-zones for the traffic pairing, will allow only that traffic flow that is listed in the address.
So take a zone with 10 interfaces and is called "trust", All 10 interfaces and network(s) behind them will NOT be automatically allowed by a rule unless you wrote it poorly by using "all or any".
( here's an example of zone named:trust with 5 interfaces )
show security zones trust
Security zone: trust
Send reset for non-SYN session TCP packets: Off
Policy configurable: Yes
Interfaces bound: 5
Interfaces:
ge-0/0/1.0
ge-0/0/2.0
ge-0/0/3.0
ge-0/0/4.0
ge-0/0/5.0
( networks 192.168.{1..5}.0/24 }
So a rule written with src-address match and ALL will cover all 5 networks. But that would be a very bad rule unless that is what you really wanted.
A proper rule would have the specific subnets or hosts listed.
set security policies from-zone trust to-zone untrust policy ALLOWDNS match source-address INSIDE_HOST01
set security policies from-zone trust to-zone untrust policy ALLOWDNS match destination-address any
set security policies from-zone trust to-zone untrust policy ALLOWDNS match application junos-dns-udp
set security policies from-zone trust to-zone untrust policy ALLOWDNS match application junos-dns-tcp
set security policies from-zone trust to-zone untrust policy ALLOWDNS then permit
vrs
set security policies from-zone trust to-zone untrust policy ALLOWDNS match source-address any
set security policies from-zone trust to-zone untrust policy ALLOWDNS match destination-address any
set security policies from-zone trust to-zone untrust policy ALLOWDNS match application junos-dns-udp
set security policies from-zone trust to-zone untrust policy ALLOWDNS match application junos-dns-tcp
set security policies from-zone trust to-zone untrust policy ALLOWDNS then permit
The proper rule authoring is a must if you want to be tight within the security policy. The use of "any" should be scrutinized very closely to ensure the proper security practices are being used.
This holds true regardless of the firewall model type or vendor.
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
^ ^
=( @ @ )=
o
/ \
Wednesday, December 4, 2019
Finding un-used junos SRX policies
In the SRX platform is ideal to audit commands to find policies that are not being used. Typically if you have a policy that is showing "zero" hits it's a clue that the policy is one of the following
1: written wrong from src/dst or both
2: service port is incorrect ( wrong port(s) #s )
3: src/dst zone is wrong or does not match the traffic flow
4: traffic is not being received by the policy forwarding engine
5: a higher up policy is trumping the policy ( policy ordering and sequence )
6: the requirement no longer exists ( the project has fizz out or been eliminate )
The junos command "show security policies hit-count less-than 10" could be executed to find all policy that has low or no matches
As you can see a few policies have zero matches. In a SOC, you would investigate and take appropriate action to remediate or eliminate the policy if required.
My general rule ; " if you have a policy-set and a firewall with considerable uptime, and certain policies are showing zero hits, then they are not required or one of the earlier items listed is applicable " .
NSE ( network security expert) and Route/Switching Engineer
1: written wrong from src/dst or both
2: service port is incorrect ( wrong port(s) #s )
3: src/dst zone is wrong or does not match the traffic flow
4: traffic is not being received by the policy forwarding engine
5: a higher up policy is trumping the policy ( policy ordering and sequence )
6: the requirement no longer exists ( the project has fizz out or been eliminate )
The junos command "show security policies hit-count less-than 10" could be executed to find all policy that has low or no matches
As you can see a few policies have zero matches. In a SOC, you would investigate and take appropriate action to remediate or eliminate the policy if required.
My general rule ; " if you have a policy-set and a firewall with considerable uptime, and certain policies are showing zero hits, then they are not required or one of the earlier items listed is applicable " .
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
^ ^
=( @ @ )=
o
/ \
Monday, December 2, 2019
Forcepoint elements creator script
In forcepoint you have the means to import elements into the SMC. You can import csv host objects from a text file. If you want to create elements and deliver these to use I have a script that does groups , hosts and network elements and creates the finally formatted xml files.
[SOF]
[EOF]
A very simple means to build a export.xml file
NSE ( network security expert) and Route/Switching Engineer
[SOF]
#!/bin/bash
#
# kfelix socpuppets.com
# rev1.0
# date oct15-2019
#
# Script for CSV supplied customer data { e.g field1,field2,field3 }
# Purpose of this script is to assist with building a bulk list of "hosts" or "Networks" objects based on a customer provided "space" separated details in a text file
#
# It should expedite any "Host or Network" elements, which can be easily imported into the SMC after zip compressing the xml datafile
# The hostfile must contains single line entries space separate hostname and ipv4 address
# The networkfile must contains single-line entries csv separate network-name and network_number and netmask in dot.dot.dot.dot format or CIDR
# e.g wwww1,1.1.1.1
# wwww2,1.1.1.2
# wwww3,1.1.1.3
# e.g net10,10.0.0.0 8
# net192.168.1.0,192.168.1.0,255.255.255.0
ntwrk 10,10.0.0.0,8
# e.g groupname
######### ensure names do not have any spaces , try to use _ - enlew of spaces in the names #############
######### script does not check the validation of the network number and netmask ; nor the host ipv4 address format ###########
#
# start of menu selections
#
#
PS3='Please enter your choice: '
opt=("GenerateHosts" "GenerateNetworks" "GenerateGroups" "Quit")
select opt in "${opt[@]}"
do
case $opt in
"GenerateHosts")
echo "Building Host Entries using filename $1"
D=`date +'%s'`
TMP=GeneratedHostImport.$D.xml
read -p "Press [Enter] key to start"
echo "<?xml version='1.0' encoding='UTF-8'?>" >> $TMP
awk 'BEGIN { print "<!DOCTYPE generic_import_export SYSTEM \x22generic_import_export_v5.10.dtd\x22>"}' >> $TMP
awk 'BEGIN { print "<generic_import_export build=\x22"10714"\x22 update_package_version=\x22"1175"\x22>" }' >> $TMP
# add host entrys to temp file
#
cat $1 | awk -F "\"*,\"*" ' { print "\<host name=\x22"$1"\x22> <mvia_address address=\x22"$2"\x22/> \n</host>"}' >> $TMP
echo "</generic_import_export>" >> $TMP
#
echo "job Completed, please see the resulted in xml filename $TMP"
exit
;;
"GenerateNetworks")
echo "Building Network Entries using filename $1"
D=`date +'%s'`
TMP=GeneratedNetworkImport.$D.xml
read -p "Press [Enter] key to start"
echo "<?xml version='1.0' encoding='UTF-8'?>" >> $TMP
awk 'BEGIN { print "<!DOCTYPE generic_import_export SYSTEM \x22generic_import_export_v5.10.dtd\x22>"}' >> $TMP
awk 'BEGIN { print "<generic_import_export build=\x22"10714"\x22 update_package_version=\x22"1175"\x22>" }' >> $TMP
# add host entrys to temp file
#
cat $1 | awk -F "\"*,\"*" ' { print "\<network db_key=\x22"7900"\x22 ipv4_network=\x22"$2"/"$3"\x22 name=\x22"$1"\x22/>" }' >> $TMP
echo "</generic_import_export>" >> $TMP
#
echo "job Completed, please see the resulted in xml filename $TMP"
exit
;;
"GenerateGroups")
echo "Building Group Entries using filename $1"
D=`date +'%s'`
TMP=GeneratedGroupImport.$D.xml
read -p "Press [Enter] key to start"
echo "<?xml version='1.0' encoding='UTF-8'?>" >> $TMP
awk 'BEGIN { print "<!DOCTYPE generic_import_export SYSTEM \x22generic_import_export_v5.10.dtd\x22>"}' >> $TMP
awk 'BEGIN { print "<generic_import_export build=\x22"10714"\x22 update_package_version=\x22"1175"\x22>" }' >> $TMP
# add host entrys to temp file
#
cat $1 | awk -F "\"*,\"*" ' { print "\<group name=\x22"$1"\x22/>"}' >> $TMP
echo "</generic_import_export>" >> $TMP
#
echo "job Completed, please see the resulted in xml filename $TMP"
exit
;;
"Quit")
break
;;
*) echo "invalid option $REPLY";;
esac
done
[EOF]
A very simple means to build a export.xml file
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
^ ^
=( @ @ )=
o
/ \
Monday, November 4, 2019
FortiOS config grabber using the API and cURL
As you probably know, I like curl and here's a simple configuration grabber than will work on Fortigates that has a API_USER.
https://en.wikipedia.org/wiki/CURL
This script will pull the complete configuration in a multi-vdom setup. And is simple and effective at grabbing a in-the-clear configuration from a fortigate using a API call
"/api/v2/monitor/system/config/backup/"
The basic meat of my script has the following, you can customize to meet your requirements.
The script will dump the configuration out via curl into the named filed
You can play around with the script to suit your needs and desires. You could probably apply the same API_KEY and for loop the scripts against a set of FGT on a cron job to grab the configurations like daily/weekly/monthly.
Other options would be to redirect to mail and sendmail the configuration file to a mail-list or user

NSE ( network security expert) and Route/Switching Engineer
https://en.wikipedia.org/wiki/CURL
This script will pull the complete configuration in a multi-vdom setup. And is simple and effective at grabbing a in-the-clear configuration from a fortigate using a API call
"/api/v2/monitor/system/config/backup/"
The basic meat of my script has the following, you can customize to meet your requirements.
SOCPUP1>cat fgtcfggrabber.sh
# rev 1.0 July 2 2019 test in fortiOS 6.Xs versions
#
#
# check for help
if [ "$1" == "-h" ]; then
echo "Usage: scriptname hostname token_key "
echo ""
echo "Example: <scriptname.sh> 193.0.2.88 MyBigLongAPI_KeyHereBlahBlahBlah"
# bye bye
# bye bye
exit 0
fi
# check if no value set for cli
if [ -z "$1" ]; then
echo "Please provide hostname and key"
echo "Use -h to see usage example!"
exit 0
fi
# grab confgurations from fortigate appliance that has API
# NET-SEC Engineer "kfelix@socpuppets.com" Ken Felix
#
# API_USER must have access write to FGT and vdoms
# set date for curl to write the file name
D=`date +%F_%T%S`
curl -k -o $1_$D.conf -H "Authorization: Bearer $2" "https://$1/api/v2/monitor/system/config/backup/?scope=global&access_token=$2"
exit
The script will dump the configuration out via curl into the named filed
You can play around with the script to suit your needs and desires. You could probably apply the same API_KEY and for loop the scripts against a set of FGT on a cron job to grab the configurations like daily/weekly/monthly.
Other options would be to redirect to mail and sendmail the configuration file to a mail-list or user
Upon execution, the output would be direct to the systemmail.
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
^ ^
=( @ @ )=
o
/ \
Subscribe to:
Posts (Atom)













