New Member

Solved

Firewall Hardening for PCI Compliance

Forum|Forum|11 years ago
September 30, 2014
13 replies
27803 views

Hi, Does anyone have an overall guideline or check-list for hardening a 1000c. The firewall is currently being used for web filtering and application control, I will be adding some simple DLP sensors and IPS also. pj

Best answer by neonbit

The FortiGate Admin guide has a section on PCI compliance here which goes through some of the ways you can harden your FortiGate to comply with PCI.

emnoc

New Member

That' s a subjective matter. In the PCI compliance guide you will not find one single guide that give specifics for firewall and each auditor seems to target various issues. PCI is wholeness complete compliance and the firewall is just one of many. The only vendor that I' m aware of that has a very broad checklist is dell sonicwall http://www.sonicwall.com/us/en/solutions/Solutions-PCI-Compliance.html#tab=bestpractices You can incorporate some of these items into your practices. Ken

Istvan_Takacs_FTNT

Staff

You can also try to enable FIPS mode on the host. It will require restart and wipe the config, but will turn on/off many features that would make the host at least FIPS-CC compliant. If the requirement is to harden the host than it will harden it for you, not sure though if it helps with the PCI one, but you may want to have a look.

emnoc

New Member

FIPS is a good suggestion , but beware of what you can' t use , and if it meets your business model. e.g vpn protocols are greatly enhanced or selection reduced. Check out a recent blog I wrote about FIPS & fortigate. http://socpuppet.blogspot.com/2014/09/hardening-your-fortigate-firewall-by.html And once again FIPS has nothing todo with PCI-DSS compliance. And PCI compliance is not FIPS. PCI-DSS covers ever thing from securing data, passwords, backup, logging,access controls, encryption of data in transit and at rest & security audit/checks on a regular basis. FIPS certification just means you systems has ran thru a stringent check for crypto standards and you meet all of the required minimum checks and now your endorsed as FIPS certified & now you can offer your product on the GSA schedule as FIPS certified and approved. FIPS is about cryptology checks and requirements, where as PCI-DSS is about systems protection for cardholder data.

Frosty

New Member

Belatedly adding from my experiences of the past few months.

Some of the things I have had to do in relation to SSL VPN functionality for PCI DSS compliance:

* installed a certificate from a trusted third-party CA for our SSL VPN connections (instead of using self-signed cert)

* disabled SSL 3.0, TLS 1.0 and TLS 1.1 connections for the SSL VPN

* set encryption/cipher algorithms to High level instead of Default (disables insecure ciphers like RC4; I think?)

* contact ISP and set up reverse DNS lookup from firewall IP to host name that matches our wildcard cert

FatalHalt

New Member

Stephen Frost wrote:
Belatedly adding from my experiences of the past few months.
Some of the things I have had to do in relation to SSL VPN functionality for PCI DSS compliance:
* installed a certificate from a trusted third-party CA for our SSL VPN connections (instead of using self-signed cert)
* disabled SSL 3.0, TLS 1.0 and TLS 1.1 connections for the SSL VPN
* set encryption/cipher algorithms to High level instead of Default (disables insecure ciphers like RC4; I think?)
* contact ISP and set up reverse DNS lookup from firewall IP to host name that matches our wildcard cert

Sounds like the exact process I'm working on!

neonbitAnswer

New Member

The FortiGate Admin guide has a section on PCI compliance here which goes through some of the ways you can harden your FortiGate to comply with PCI.

emnoc

New Member

FWIW & IMHO that links is useless without reference to the actual PCI DSS specifications. IMHO experiences and thru various audits, you 're best to read/review the actual PCI DSS "Requirements and Security Assessment Procedures" document. It's only like 100 pages and 12 major areas with like 4-5 that really deals wth network, systems and firewalls. It would take you less than 1-2 hour to read it for a average reader.

OP, keep this thought in mind ; " as log as you read the areas that applicable to you and can demonstrate that you meet that requirement ( paragraph and all sub-paragrahs )". Then you will always PASS a audit.

Some things will be nik-picked on like " disabling of unused accounts or re-use of passphrases " ( both of these are very hard to do without a remote authentication system aka .....authenticator radius etc.....

So read the actual PCI DSS document, FIPS mode will get you by on any weak cipher and security protocols, but PCI-DSS is more than just that & is a complete practical procedure from end2end and everything in between.

Frosty

New Member

I could use some input from others with more experience. Having followed the instructions here:

https://stuff.purdon.ca/?page_id=83

I've successfully imported a valid wildcard certificate issued by a proper third-party CA (GeoTrust). The wildcard cert is now being used for SSL VPN connections. So far so good.

My question concerns the entirety of the cert's chain ... the Intermediate and the Root signing authority certs.

These have NOT been installed to our Fortigate. The SSL VPN is working fine. But we are getting an error when we do a PCI vulnerability scan. The scan is not recognising the validity of the CA. Is this because I have not also installed the Intermediate and Root certs to the Fortigate? Or is it because there's an issue with the Qualys scan system and *it* is at fault.

What have others done when installing third-party CA certs ... install Intermediate and Root certs ... or not?

If installing, do they all go into the Local Certificates store, or ... ?

EDIT: in the meantime I have flagged the issue as a False Positive and this has been accepted by Qualys ... but I would still be interested to know what others have done when installing 3rd-party CA certs.

seadave

New Member

Stephen Frost wrote:
I could use some input from others with more experience. Having followed the instructions here:
https://stuff.purdon.ca/?page_id=83
I've successfully imported a valid wildcard certificate issued by a proper third-party CA (GeoTrust). The wildcard cert is now being used for SSL VPN connections. So far so good.
My question concerns the entirety of the cert's chain ... the Intermediate and the Root signing authority certs.
These have NOT been installed to our Fortigate. The SSL VPN is working fine. But we are getting an error when we do a PCI vulnerability scan. The scan is not recognising the validity of the CA. Is this because I have not also installed the Intermediate and Root certs to the Fortigate? Or is it because there's an issue with the Qualys scan system and *it* is at fault.
What have others done when installing third-party CA certs ... install Intermediate and Root certs ... or not?
If installing, do they all go into the Local Certificates store, or ... ?

EDIT: in the meantime I have flagged the issue as a False Positive and this has been accepted by Qualys ... but I would still be interested to know what others have done when installing 3rd-party CA certs.

You probably figured this out by now, but you need to install all of the certs that come in the bundle from your CA for it to work. You use Certificates...Import...CA Certificate for the TrustedRoot.crt and VendorNameCA.crt (I bought mine from Digicert).

After the Trusted Root and Intermediate certs are installed, you use Certificates...Import...Local Cert and select the cert issued by your CA based on the CSR you sent them. Some things to note:

Using and Extended Validation (EV) cert will break firmware 5.2.3. You can generate the CSR, but when you import the signed cert provided by your CA, it will turn the cert UI white making it unusable. Upgrading to 5.2.4 fixes this issue, but 5.2.4 has problems with multi-WAN and SSL (based on other forum posts) so be careful if you need that. I have two brand new 500Ds that I've been testing this with fairly simple configs, and I have confirmed the above regarding EV certs working on .4 but not .3.

If you want to get the best rating from the Qualys test site: https://www.ssllabs.com/ssltest/index.html

you should do the following:

-Consider using a Elliptic Curve instead of RSA keyed cert. RSA is not aging well and various sources have indicated that properly funded parties are better able to compromise it. When you generate the cert choose "Elliptic Curve" and "secp256r1" for the key type and curve name. (EC will not work with old browsers. Make sure you don't have some maniac at home running Windows 2000, if you do tell them to get with the program).

-Consider getting an EV cert so that your users get the nice green URL bar. I used Digicert for this. They are great.

- You need to harden your Fortinet to ensure the proper crypto algorithms and services are enabled/disabled:

config system global set strong-crypto enable end

config vpn ssl settings set sslv3 disable set algorithm high end

Again, if you do need to support legacy browser versions for some terrible reason, the above will remove SSLv3 protocol and RC4 cipher and will break compatibility (but you will be more secure). Both of these are vulnerable to compromise now and anything produced in the last 2 to 3 years will support TLS (which is essentially SSLv4) and ECDHE, so it shouldn't be an issue except for the most extreme cases. I have not had problems so far with this config.

seadave

New Member

As a follow up, here is a great article explaining ECC and why you should seriously consider using it:

https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/

emnoc

New Member

seadave has posted some very good info. EC- secp 384r1 is even being discuss as the min that should be support but I think that's the same sky is falling argument with a 2k vrs 4k bit RSA keysize . But with today's mathmatics you should be way secured for the life of your signing cert. Remember the chain is only as strong as the weakest link & if you exclude any RSA component in the cert chain & SSLv3 than you will be very secured for now and near future ;) Also your end-cert will never have a expiration date longer than the CAroot ;)

" So in another 2-4 years we will be re-discussing TLS security and it's short comings and with probably new suggestions "

Right now, you should follow the suggestions mention above, install all intermediate CAs so our cert-trust chain is not broken.

Than tighten up your endpoint, almost all modern browsers support TLS and ECC , secure your trust host statements and vpns & most importantly " Follow the PCI-DSS guide " and as long as you do that, you will be always be 100% COMPLIANCE and secured.

A big thumbs up for seadave reply, these items are always overlooked imho.

Frosty

New Member

Thanks for the extra info posted. I'd dropped this issue for a few weeks due to other priorities. I've now imported both the Intermediate and the Root CA certs from GeoTrust, as per the advice from 'seadave'. Since the import process gave them default names like CA_Cert_1 and CA_Cert_2, I went back in to the CLI and renamed these as "GeoTrust-Intermediate-CA" and "GeoTrust-Root-CA" respectively. All seems okay. Fingers crossed.

Thanks also for mentioning some of the other hardening CLI commands. I had already picked up on those, some by my own research, but others only via logging a ticket with Fortinet. So I do now have a "clean scan" from Qualys, at least on the external stuff.

maednurm

New Member

Stephen > can you please send me PM or an email mati(at)aednurm.ee with a short description of "some other hardening CLI commands". I'm struggling to get clean scan, DH key exchange more specifically...

Thanks a lot!

Sign up

Login with SSO

Login to the community

Login with SSO