FTNT has done it again, a new release for MACOSX forticlient. The release lists a few new items and issues and the upgrade from a 5.2.x version is flawless
Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
^ ^
=( @ @ )=
o
/ \
Sunday, October 11, 2015
Importing pkcs format certificate into windows ( forticlient )
In this blog we will look at the general steps for importing a pkcs encode certificate into a windows system. The steps are very similar across all of the windows OS versions.
Windows uses pkcs specifically, where most open source and unix systems requires PEM encoded. So keep this in mind when handling user certficates for vpn access.
In my case, my certificates are already pkcs format. You can tell if a certificate is pkcs format if it binary data.
e.g ( using openssl )
note: the openssl cmd openssl pkcs12 -in cert_name_here.p12 -info -nokeys , is a good method for gain information on a certificate.
Now here's the steps uses to import a certificate using the window cert manager. The certificate manager is simple to use and very reliable.
step1: start the certificate manager by typing certmgr.msc from a windows cmd prompt or by double clicking a pkcs12 certificate. Take heed of the support certificate types.
step2: Type the passphrase for the certificate and if you select "export" this will let you save and export the certificates if you ever need to export to a different host.
step3: Windows manages storage quite well but you can manually override the automatic storage by selecting a location. "Users" Certificate should go into the Personal > Certificates label and others by the intended purpose or for systems purpose. Certificate installed for a user is readable by just that "user" where as admin has rights to all certificates.
step4: if you have a self-sign certificate be aware of the warning for the lack of CA trust chain.
If the certificate was imported with no errors, you will have a success dialog window. And after a restart of the forticlient, the certificates will be available.
Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
^ ^
=( @ @ )=
o
/ \
Windows uses pkcs specifically, where most open source and unix systems requires PEM encoded. So keep this in mind when handling user certficates for vpn access.
In my case, my certificates are already pkcs format. You can tell if a certificate is pkcs format if it binary data.
e.g ( using openssl )
note: the openssl cmd openssl pkcs12 -in cert_name_here.p12 -info -nokeys , is a good method for gain information on a certificate.
Now here's the steps uses to import a certificate using the window cert manager. The certificate manager is simple to use and very reliable.
step1: start the certificate manager by typing certmgr.msc from a windows cmd prompt or by double clicking a pkcs12 certificate. Take heed of the support certificate types.
step2: Type the passphrase for the certificate and if you select "export" this will let you save and export the certificates if you ever need to export to a different host.
step3: Windows manages storage quite well but you can manually override the automatic storage by selecting a location. "Users" Certificate should go into the Personal > Certificates label and others by the intended purpose or for systems purpose. Certificate installed for a user is readable by just that "user" where as admin has rights to all certificates.
step4: if you have a self-sign certificate be aware of the warning for the lack of CA trust chain.
If the certificate was imported with no errors, you will have a success dialog window. And after a restart of the forticlient, the certificates will be available.
Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
^ ^
=( @ @ )=
o
/ \
Thursday, October 8, 2015
Forticlent registering
Here's a few screen shots of a fortiClient and the discover between a client and fortigate over wireless.
A fortigate will use fortiClient dicovery if enabled over the interface or you can manually set the fortigate device. It uses tcp/8010 for registering and KeepAlives.
If you have any profile these will be pulled by the fortiClients. You can also use the fortiManager for managing fortiClients.
Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
^ ^
=( @ @ )=
o
/ \
A fortigate will use fortiClient dicovery if enabled over the interface or you can manually set the fortigate device. It uses tcp/8010 for registering and KeepAlives.
If you have any profile these will be pulled by the fortiClients. You can also use the fortiManager for managing fortiClients.
Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
^ ^
=( @ @ )=
o
/ \
The FortiClient and cisco VPN ( ipsec )
Forticlient is a client software that supports a host of function 2 of which are vpn access ( ipsec & ssl ) .
It's developed by Fortinet, but you can use it with a cisco ASA or Router as a dialup vpn client.
You can even use it with pfSense for example, or just about a few other dialup ipsec-vpn-devices if you care to edit the xml section under your ipsec connection details and tweak the configurations.
The key for using the client is to modify the xml as required to fit your vpn dialup concentrator. For access these XML tags should be scrutinize and double check. You might need to ask your firewall/vpn administrator for guidance )
here's snippet of a vpn ipsec connection profile for a cisco device
And here's our client accessed to our vpn;
Some key-points;
Here's a few warnings based on my experience
( mis-match pre-share key)
( mis-match in either ike or ipsec dhgrp or ciphers proposal )
The FortiClient does not support ikev2
If the PSK does not match, you will never make it to user authentication ( eXended Authentication aka xauth )
I've never had any luck with defining < FQDN mypeerid> on pfsense and using the name@domain format use the keytagID
Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
^ ^
=( @ @ )=
o
/ \
It's developed by Fortinet, but you can use it with a cisco ASA or Router as a dialup vpn client.
You can even use it with pfSense for example, or just about a few other dialup ipsec-vpn-devices if you care to edit the xml section under your ipsec connection details and tweak the configurations.
The key for using the client is to modify the xml as required to fit your vpn dialup concentrator. For access these XML tags should be scrutinize and double check. You might need to ask your firewall/vpn administrator for guidance )
- <dhgroup>
- <localid> ( if your using groups )
- <proposals> ( crypto ciphers are crucial and need to match )
here's snippet of a vpn ipsec connection profile for a cisco device
And here's our client accessed to our vpn;
Some key-points;
- the forticlient is very versatile as a ipsec client
- it can be used with fortigate and non-Fortigates but requires some tweaking
- XML editing is a must ( make backup before imposing changes )
- validate all profile settings ( Diffie-Hellman, proposals, etc....)
- populate the <localid> if your using vpn groups in your dialup
Here's a few warnings based on my experience
( mis-match pre-share key)
( mis-match in either ike or ipsec dhgrp or ciphers proposal )
The FortiClient does not support ikev2
If the PSK does not match, you will never make it to user authentication ( eXended Authentication aka xauth )
I've never had any luck with defining < FQDN mypeerid> on pfsense and using the name@domain format use the keytagID
Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
^ ^
=( @ @ )=
o
/ \
Wednesday, October 7, 2015
fortigate radius observations
In this blog, I will point out some radius ( freeradius )
and fortigate observations for firewall administration. RADIUS offers
authentication & accounting for users and administration. FreeRadius has
been around for many years now. It’s an opensource package that compile very
well and can as backend for TACACS proxy. It also support
user account information in mysql database format if you so desire. In fact most of
the bigger ISPs uses mysql for holding user account details.
With in freeradius
you need to define the NAS client which is our firewall;
e.g ( freeradius clients.conf file )
client 10.10.80.1
{
secret
= key1234567890
shortname =
FGT
}
The format is very simple, you define a network or host and
the radius key. If you wanted to define a network use a format similar to below ;
client 10.10.80.0/24 {
secret =
key1234567890
shortname = LANipv4
}
client 2001:db8:199::0/64 {
secret =
key1234567890
shortname = LANipv6
}
as of 5.2.x ipv6 radius clients are not support for fortiOS
Now moving on, the radius user file contains our users details ( name, password attributes,etc....). I will demo a few types but the user password type can be any of the various methods;
Type one “crypt password”
"ken.felix"
Crypt-Password :=
"6h8yRBvqLKIo6"
Service-Type = NAS-Prompt-User,
Fortinet-Access-Profile = "noneprofile",
Cisco-AVPair = "shell:priv-lvl=15",
Reply-Message = "Hello, SOCRADIUS1
welcomes %{User-Name}"
Type two “md5
password”
ken" MD5-Password :=
"pZnTbEx6cd3MG8clmhWsOg=="
Service-Type = NAS-Prompt-User,
Fortinet-Access-Profile = "noneprofile",
Cisco-AVPair = "shell:priv-lvl=15",
Reply-Message = "Hello, SOCRADIUS1
welcomes %{User-Name}"
Type three a “cleartext
password”
radchk Cleartext-Password
:= "test0123456789"
Reply-Message = "Hello, SOCRAD01
welcomes %{User-Name}",
Fortinet-Access-Profile = "super_admin",
Service-Type = NAS-Prompt-User,
Cisco-AVPair = "shell:priv-lvl=0"
These types should be self-describing but if in doubt please
refer to my earlier post here.
Okay now, on the NAS side ( fortigate ) our radius
configuration is very simple. You can define within the latest FortiOS version
upto 3x radius-severs. Each can have a different radius-key BUT you can’t use
different radius-auth-ports or authentication types { PAP|CHAP|msCHAP| )
So all defined radius-servers entries MUST HAVE THE SAME DETAILS for auth-ports.
e.g ( configurations from a production fortigate radius-server config user radius )
config user radius
edit "LASANCA11RAMPARTSAA"
set server
"172.16.179.100"
set secret
J3k484kdRad02sefgsec
set timeout
12
set
all-usergroup disable
set
use-management-vdom disable
set nas-ip
0.0.0.0
set
acct-interim-interval 600
set
radius-port 1812
set
h3c-compatibility disable
set
auth-type auto
set
source-ip 0.0.0.0
set rsso disable
set
secondary-server "172.16.178.101"
set
secondary-secret myRad1@393J3kdlSec
next
end
Now on the fortigate
admin side you have to be aware of two
issues. Fortinet allows for a specific user(s) or wildcards users * admin accounts. What
this means;
A specific user is a account that placed on the fortigate and with remote-auth where as a
wildcard is a generic “anybody”. The latter is use where you need to
ensure multiple admins and have no time
or desire for crafting dozens or hundreds of users accounts. This is typically
what you see in a big outfit like a large business, ISP, NOC, SOC, or a MSSP.
NOTE: A local define account will ALWAYS be authenticated
locally. So if you have wildcards and a
local user ( with no remote-auth enable ) &
with the same network in your radius-server, the radius-server will
never be offered the authentication request.
Speaking of requests, RADIUS Authentication is a 2 format
protocol. Typically you have a request and then a response if the client is an allowed NAS client and it has a matching radius-key.
( interesting tidbit of facts )
Radius has been around
for many years. Most RADIUS solutions today are built around the earlier LIVINGSTON radius. Livingston offer a dialup
modem bank back in the day when we had dialup-ppp accounts and had a great and well
defined AAA solution. I believe IIRC
that engineers/designers of Livingston was the main drafter of the current RADIUS protocol.
Now the user account it trivial to setup.
Here’s a local user;
config sys admin
edit "radchck"
set remote-auth enable
set accprofile "super_admin"
set vdom "root"
set remote-group "radius"
set accprofile-override enable
end
Here’s a wildcard;
config sys admin
edit "WILDCARD"
set remote-auth enable
set accprofile "prof_admin"
set vdom "root"
set wildcard enable
set remote-group "radius"
next
Okay before we
get to the above, we need to specify a
group and named the “RADIUS SERVER” in that group as a member. I kept my group name
simple by naming it radius.
SOC60D
(root) # show user group radius
config
user group
edit "radius"
set member "TEST"
next
end
look at is as the group is a
local account that’s matched to a authentication method, This allows you to mix
and match let’s LDAP TACACS and RADIUS
Okay now
let’s dive in and look at some radius details from these screenshots;
PAP vrs CHAP, notice how the password is encrypted in the CHAP challenge. by temporary enabling PAP allows for you to debug wrong passwords on the freeradius server.
Here's a single radius-server configuration on a FGT60D ;
Here's a show output for a wildcard user and the details for the last logins;
Using radtest for testing radius user access and validation for chap with the user password.
Using radtest for testing radius user access and validation for pap with the user password.
Dashboard authentication status for our wildcard user.
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
^ ^
=( @ @ )=
o
/ \
Fortimail greylist db resetting
The Fortimail appliances has a few tricks up the sleeves with regards to the greylist DB. To reset the DB from the cli which is the only means that I know of, you have to use the
execute db reset greylist command
This will flush all greylisted database entries;
To monitor the greylisting status, You can use either of the following;
WebGUI
Monitor > greylisting
You can adjust the greylist capacity via the following command;
config antispam settings
set greylist-capacity 250000
end
Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
^ ^
=( + - )=
o
/ \
execute db reset greylist command
This will flush all greylisted database entries;
To monitor the greylisting status, You can use either of the following;
WebGUI
Monitor > greylisting
You can adjust the greylist capacity via the following command;
config antispam settings
set greylist-capacity 250000
end
Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
^ ^
=( + - )=
o
/ \
Fortigate configuration files backups ( understanding )
In this post we will look a a configuration file of a typical fortigate and the many means for configuration backup. 1st the configuration is a simple text file that can be read or edit by a reader/edit application ( Vi/Ed/Word/text-editor )
The configuration file for the unit that it was created, has a few key items as shown in the following image.
NOTE: All of these 1st 3 lines are crucial if you ever need to restore a backup on a another unit.
The fortigate allows for you generated a encrypted configuration file. The encryption cipher used in this configuration is unknown and not public knowledge, but you will NOT be able to review or modify the configuration of a encrypted file.
e.g encrypted configuration file content
NOTE: This is why I recommend using a local encryption utilities & if you ever need off-appliance storage of a security appliances cfg-files and if you need to securely transmit for others to review such as a "auditor" or "support" engineer. Openssl or GPG would come in handy for this.
Now moving along, the configuration can be backed up via a few simple means
1: locally to a usb drive
2: using a screen capture or buffer capture from your telnet/ssh session
3: via the execution of the backup via the WebGUI
You choice would be determine based on your policy and local environment. Example, a agency I contracted with only allowed ssh access to their fortigates, so your choices for backups was limited.
The backup configuration should always be secured regardless of what method or access you use.
The backup is always named in the following manner; <hostname>_YEAR2DIGITMONTHDATE.conf
This makes for retrieving the backup file very easy and simplified. If the 1st 3 lines of any configuration files are missing or corrupt the configuration file will be ignored and the unit will kick out a error.
Another backup that should be mention, fortinet has a "fortimanager" appliance that can perform configuration management, archive and deployment
http://www.fortinet.com/fortimanager_product_demo.html
The Web GUI backup allows you to do the following with ease;
The command line access also give you the same ability. Always get into the habit of regular backups and automated backups
sample bash script
#!/bin/bash
# This is a simple bash cfg grabber
#
#
if [ ! $1 ]; then
echo " Usage : getcfg.sg <username> <fortigate ip_address> <ssh port # > "
echo " "
echo " Example getcfg admin 1.1.1.1 22 "
echo " "
exit 1
fi
#
#
DATE=`date +%F%Z%T`
#
#
A=sys_config
#
PORT=$3
scp -P $3 $1@$2:$A ./$A-$2_$DATE.cfg
#
#
end
NOTE: I just recently found out that fgt-config can also be used in replaced of sys_config but not ALL fortigates are supporting this and "*sys_config" or anything with sys_config in the name
Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
^ ^
=( @ @ )=
o
/ \
The configuration file for the unit that it was created, has a few key items as shown in the following image.
The unit model and software build, the admin that created the file, and configuration version #s
NOTE: All of these 1st 3 lines are crucial if you ever need to restore a backup on a another unit.
The fortigate allows for you generated a encrypted configuration file. The encryption cipher used in this configuration is unknown and not public knowledge, but you will NOT be able to review or modify the configuration of a encrypted file.
e.g encrypted configuration file content
NOTE: This is why I recommend using a local encryption utilities & if you ever need off-appliance storage of a security appliances cfg-files and if you need to securely transmit for others to review such as a "auditor" or "support" engineer. Openssl or GPG would come in handy for this.
Now moving along, the configuration can be backed up via a few simple means
1: locally to a usb drive
2: using a screen capture or buffer capture from your telnet/ssh session
3: via the execution of the backup via the WebGUI
You choice would be determine based on your policy and local environment. Example, a agency I contracted with only allowed ssh access to their fortigates, so your choices for backups was limited.
The backup configuration should always be secured regardless of what method or access you use.
The backup is always named in the following manner; <hostname>_YEAR2DIGITMONTHDATE.conf
This makes for retrieving the backup file very easy and simplified. If the 1st 3 lines of any configuration files are missing or corrupt the configuration file will be ignored and the unit will kick out a error.
Another backup that should be mention, fortinet has a "fortimanager" appliance that can perform configuration management, archive and deployment
http://www.fortinet.com/fortimanager_product_demo.html
The Web GUI backup allows you to do the following with ease;
- full system backup
- specific vdom backup
- set a encryption password
- set the backup device
The command line access also give you the same ability. Always get into the habit of regular backups and automated backups
sample bash script
#!/bin/bash
# This is a simple bash cfg grabber
#
#
if [ ! $1 ]; then
echo " Usage : getcfg.sg <username> <fortigate ip_address> <ssh port # > "
echo " "
echo " Example getcfg admin 1.1.1.1 22 "
echo " "
exit 1
fi
#
#
DATE=`date +%F%Z%T`
#
#
A=sys_config
#
PORT=$3
scp -P $3 $1@$2:$A ./$A-$2_$DATE.cfg
#
#
end
NOTE: I just recently found out that fgt-config can also be used in replaced of sys_config but not ALL fortigates are supporting this and "*sys_config" or anything with sys_config in the name
Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
^ ^
=( @ @ )=
o
/ \
Tuesday, October 6, 2015
How to import a certficate into MACOSX for ipsec vpn
In this blog, I will show you how we export a pfSense generate certificate and re-import the certificate as a pkcs12 format certificate into MACOSX 10.10.x.
1st you need to find the user certificate and export the certificate+key files from pfsense. This is the 1st step.
Your firewall administrator should have already generate a signer CA and have a master certificate to sign from. He/She will execute this step.
This above step will create 2 named files. These files should be secured and passphrase protected imho. To not leave these around and use a strong passphrase
e.g
BAD = mypassword
Good = Her2kssedfgj
Better = Heirs mein3 assP3hdy3 Se3nd mdededdd
Here's the certificate manager on a pfsense-firewall and the highlight download buttons that we will use to download the certificate and key ( x509+ RSA formatted )
don't download the pkcs format file, it's tempting but you must have a set passphrase when importing into MACOSX we will set a passphrase on the conversion step using openssl
Take the certificate and key files and convert these into pkcs12 ( aka p12 ) format using openssl;
https://en.wikipedia.org/wiki/PKCS_12
Now to import the newly crafted certifcate, you can open the MACOSX KeyChain access utility;
1: provide authentication in order to make changes to the keychain access ( your credentials )
2: import the certificate into system > my certificate
3: supply the passphrase that you have set during the x509 to pkcs conversion.
4: close the key chain utility
Once this has been done, you can now select the certificate in your MACOSX vpn-client details;
Ensure you select the right certificate for that user and installed the correct username in the vpn_client profile
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
^ ^
=( @ @ )=
o
/ \
1st you need to find the user certificate and export the certificate+key files from pfsense. This is the 1st step.
Your firewall administrator should have already generate a signer CA and have a master certificate to sign from. He/She will execute this step.
This above step will create 2 named files. These files should be secured and passphrase protected imho. To not leave these around and use a strong passphrase
e.g
BAD = mypassword
Good = Her2kssedfgj
Better = Heirs mein3 assP3hdy3 Se3nd mdededdd
Here's the certificate manager on a pfsense-firewall and the highlight download buttons that we will use to download the certificate and key ( x509+ RSA formatted )
Take the certificate and key files and convert these into pkcs12 ( aka p12 ) format using openssl;
https://en.wikipedia.org/wiki/PKCS_12
Now to import the newly crafted certifcate, you can open the MACOSX KeyChain access utility;
1: provide authentication in order to make changes to the keychain access ( your credentials )
2: import the certificate into system > my certificate
3: supply the passphrase that you have set during the x509 to pkcs conversion.
4: close the key chain utility
Once this has been done, you can now select the certificate in your MACOSX vpn-client details;
Ensure you select the right certificate for that user and installed the correct username in the vpn_client profile
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
^ ^
=( @ @ )=
o
/ \
Subscribe to:
Posts (Atom)