Tag Archives: harden

FortiGate Securing Remote Administration

Posted on by
4

KB ID 0001734

Problem

When considering Securing FortiGate  remote administration, I’ve written about changing the https management port to something other than TCP 443 before, I suppose that’s security by obfuscation (though even a script kiddy with one hours experience, will be able to spot an html responses).  Typically with other vendors you limit remote administration access, to specific IP addresses (or ranges). So how to do the same in Fortigate?

FortiGate Trusted Hosts

With FortiGate the approach is slightly different, (to Cisco anyway) in that, you allow access from ‘Trusted Hosts‘ and you do that ‘Per Administrator’ not for the entire remote access solution (like HTTPS or SSH). On reflection I like this, because by default you will have a user called ‘admin’ and an attacker will ‘possibly’ know that. With FortiGate you can restrict the admin account so it can only log on from inside, or from management hosts/networks or from an Out of Band management network.

You can also give an administrative password to one partner and only allow access from that partner’s public IP/Range, or if like my firm we need to support a lot of firewalls we can hard code this into our default deployments and retain remote administration. (Though FortiManager is the direction you want to be headed in, for that!)

Configure FortiGate ‘Per Administrator’ Trusted Hosts.

System > Administrators > Create New > Administrator.

Create a username/password > Select the admin level required > Enable ‘Restrict Login to Trusted Hosts’

Here’s an example where the admin account can only manage the firewall form the 192.168.1.0/24 network, and a management host 192.168.2100.3 For ‘external‘ access I’ve got a new administrator, who can get access from my management host, (for belt and braces), a single public network, and a public IP address.

Related Articles, References, Credits, or External Links

NA

Cisco ASA – Disable SSLv3 (Force TLSv1.0) – Mitigate POODLE

Posted on by

KB ID 0001052

Problem

By default the Cisco ASA will allow connection via SSLv3. The POODLE exploit works by forcing SSL to fall back to SSLv3 and then decrypting that communication. However you are still not completely protected as per this Threat Validation, so the ASA platform can still be attacked via TLSv1.0. Note: At time of writing TLSv1.2 is not supported, but it is on the road-map for version 9.3(2).

So this procedure will not completely eliminate the threat, but it’s as mitigated as it’s possible to be at this time, (And TLSv1 is considered more secure than SSLv3 anyway).

Solution

1. You can check your firewall is contactable via SSLv3, here I’m on MAC OSX and I’ve got OpenSSL installed. If I try to initiate an SSLv3 connection it works.

[box] openssl s_client -connect {IP_or_Hostname} -ssl3 [/box]

Or if you have nmap installed you can use that as well;

[box]nmap –script ssl-enum-ciphers {IP_of_Hostname}[/box]

2. Below you can see I’m confirming the SSL settings (i.e. it will accept SSLv3). Then I force the firewall to only accept TLSv1.0.

[box]

Petes-ASA# configure terminal
Petes-ASA(config)# ssl client-version tlsv1-only 
Petes-ASA(config)# ssl server-version tlsv1-only

[/box]

You can see, afterwards when I view the SSL options, only TLSv1 will be accepted.

3. If you prefer to use the ADSM, then you will find the same settings at, Configuration > Remote Access VPN > Advanced > SSL Settings;

The SSL version for the security appliance to negotiate as a ‘server’ = TLS V1 Only

The SSL version for the security appliance to negotiate as a ‘client’ = TLS V1 Only

 

4. Don’t forget to ‘Apply’ and then save the changes.

Cisco ASA Testing for SSLv3

Simply perform the tests that I did above;

1. Proving the absence of SSLv3 with OpenSSL.

2. Proving the absence of SSLv3 with nmap.

Related Articles, References, Credits, or External Links

NA