find what DH group an ikev1 S2S VPN is using in ASA

Move away from Groups 2, 5, 24. 

DH Groups 2, 5, 24 are considered insecure and are deprecated in FTD’s running 6.5/6.6 and will be removed in a later version.

check 6.7 and 7.1 release notes and search for group 5

https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/device-config/710/management-center-device-config-71/vpn-s2s.html? 

IKEv1

show vpn-sessiondb detail l2l filter ipaddress x.x.x.x

Look for "D/H Group" in IKEv1 section

sh crypto isakmp sa detail | i Grp:

sh crypto isakmp sa | i PFS Group 2,

Looking for groups 2 and 5

 sh crypto isakmp sa detail | i Grp:2,

 sh crypto isakmp sa detail | i Grp:5,

Can copy the full output of " sh crypto isakmp sa detail" to a text file and search

geoblock on palo alto

The FW needs to see the IP before geoblock can be applied 

under monitor > logs > GlobalProtect

( stage eq 'login' ) and ( status eq 'success' )

Also

Network > Gateways, click on the "Remote Users" link on the right

There is also the option to create the NAT for the GP IP only for the geo locations allowed

Have a general security rules with geoblock to/from any deny

Have a security rule to allow access to the GP IP only from the approved countries

Set the countries up in the GP config (portal / gateway)

Config the geoblock on any 2FA you might be using for 2FA as well as another line of defence

Enable the palo EDL blocks and dynamic threats etc, strict IPS

NAT rules on palo alto

 Making a note because its a bit different to cisco ASA

NAT rule

OUTSIDE > OUTSIDE 

Public src > Public dst

FW rule 

OUTSIDE > INSIDE (counted as inside because of the NAT)

Public src > Public dst

palo alto mtu

 https://docs.paloaltonetworks.com/globalprotect/5-2/globalprotect-app-new-features/new-features-released-in-gp-app/configurable-maximum-transmission-unit-for-globalprotect-connections

You get prompted twice for GlobalProtect with MFA/2FA on palo alto firewall

The usual fix is to put

portal auth > AD 

gateway auth > MFA server

However we found with some OTP/fob code users it wasn't working well

Fix was 

Upgrade GP to preferred release (6.2.3 a time of writing)

Enable the authentication cookie settings on GP

Portal > Agent - Generate cookie for auth override

Choose the same cert you use for the GP 

Gateway > Agent > Client Settings > clock settings > Authenticaiton Override tab

tick Accept cookie for auth override

Choose the same cert you used in portal

Push policy

Watch out for any AD changes may take 15 mins to update on the palo so if you move a user into another group for testing it might not work for 15 minutes

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u0000004MACCA2&lang=en_US%E2%80%A9&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

create custom URL category on palo alto can be used for wildcard URLs

 If you have FQDN then you can just add FQDN object in the rule

If you want to add a wildcard or multiple URLs in a group then you can create a custom URL category

Objects -> Custom objects -> URL categories - > Add

Add your URLs

*.mail.protection.outlook.com/

smtp.office365.com/

Always end with a / ending token

Blurb from the palo:

For domain entries, we recommend you use an ending token. Acceptable tokens are: . / ? & = ; +. If you choose not to use an ending token, you may block or allow more URLs than anticipated. For example, if you want to allow xyz.com and enter the domain as 'xyz.com,' you will allow xyz.com and URLs such as xyz.com.random.com. However, if you enter the domain as 'xyz.com/,' you will only allow xyz.com.

More info here:

https://docs.paloaltonetworks.com/advanced-url-filtering/administration/configuring-url-filtering/url-category-exceptions

CLI

set profiles custom-url-category URL-CC-OSCP-CRL description "Custom URL category for OSCP"

set profiles custom-url-category URL-CC-OSCP-CRL type "URL List"

set profiles custom-url-category URL-CC-OSCP-CRL list [ crl.globalsign.net www.d-trust.net cdp1.public-trust.com crl.cnnic.cn crl.entrust.net crl.globalsign.com crl.globalsign.net crl.identrust.com crl.thawte.com crl3.digicert.com crl4.digicert.com s1.symcb.com www.d-trust.net isrg.trustid.ocsp.identrust.com ocsp.digicert.com ocsp.entrust.net ocsp.globalsign.com ocsp.omniroot.com ocsp.startssl.com ocsp.thawte.com ocsp2.globalsign.com ocspcnnicroot.cnnic.cn root-c3-ca2-2009.ocsp.d-trust.net root-c3-ca2-ev-2009.ocsp.d-trust.net s2.symcb.com aia.startssl.com apps.identrust.com cacert.omniroot.com ]

packet tracer not working well in FMC/FTD

Packet-tracer never worked well with VPN traffic, that was ok but now in FMC/FTD its also not working at all if you have snort or geoblocking rules. You will see an ip any any allow. Instead you must use the system support trace on live traffic. The whole point of packet tracer is that we don't always have live traffic or access to generate live traffic.

From cisco:

Indeed, from the packet tracer side it looks like the packet is going through in that IP permit any any, but that rule in reality does not exist.

Any rule which relies on snort will be classified by the box as a L4 permit ip any any, and unfortunately having a geodb rule looks like a snort rule for the box.

This is documented here:

https://www.cisco.com/c/en/us/support/docs/security/secure-firewall-threat-defense/218196-understand-how-lina-rules-configured-wit.html

Rules with Snort Features Are Deployed As Permit Any Any

When you create a rule with features that are run by Snort side, like Geolocation, URL (Universal Resource Locator) filter, Application detection, etc, they are deployed on Lina side as a permit any any rule.

At a first glance, this can confuse you and make you think that the FTD allows all the traffic on that rule and stops the rule match verification for the rules that follow.

We also have an enhancement request for this: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwd00446

Unfortunately, this breaks the usage of the packet tracer feature, and in this case, you should rather use “> system support trace” if there is live traffic.

install wildcard cert on palo alto firewall

Global protect portal and gateway should be setup

Get customer to get DNS record created eg globalprotect.domain.com

Point the record at the global portect portal IP (Network -> Global Protect -> Portals)

Download the wildcard cert and root/chain cert from the cert vendor (.crt format). The windows .p7b format is no good. The chain bundle cert usually publicly available. The wildcard will need to be downloaded via a login may need to get it from the customer.

Install wildcard cert on palo alto firewall

Global protect portal and gateway should be setup

Get customer to get DNS record created eg globalprotect.domain.com

Point the record at the global portect portal IP (Network -> Global Protect -> Portals)

Download the wildcard cert and root/chain cert from the cert vendor (.crt format). The windows .p7b format is no good. The chain bundle cert usually publicly available. The wildcard will need to be downloaded via a login may need to get it from the customer. Example vendor chain location:

https://certs.godaddy.com/repository

Import vendor root/chain cert bundle

Device -> certificate management -> certificates 

Click import 

Give name eg "vendor-ca-root-chain-bundle"

Select the bundle file "bundle-g2.crt"

Leave everything else and click ok

Import wildcard cert

This can be imported in a few methods (.crt) (.pfx) if its PFX you will need to include the password

Certs should look like this

 

Create SSL/TLS profile

Device -> Certificate Management -> SSL/TLS Service Profile

Name "SSL-TLS-PROFILE"

Min version: TLSv1.2

Max version: Max

Attach SSL/TLS profile to global protect portal and GW

Network -> GlobalProtect -> Portals 

Click the GP_Portal

Authentication tab 

Under server authenticaiton / SSL/TLS service profile

Select your "SSL-TLS-PROFILE" from the drop down

Configure the URL used for portal/gateway in the portal

Network -> GlobalProtect -> Portals

Click the GP_Portal

Agent 

Add the CA root and chain cert (optional to tick install in root cert store)

 

Now click on GP_Agent_Config -> External

You will need a DNS -> pub IP record setup with the external DNS vendor

Fill in the DNS name for the Gateway

 

Add the SSL-TLS profile to the gateway as well

Network -> GlobalProtect -> Gateways

Click the GP_Gateway

Authentication tab

Under server authenticaiton / SSL/TLS service profile

Select your "SSL-TLS-PROFILE" from the drop down

Change IP to URL

Go Portal - GP settings - Agent - Agent config - External

Change external gateway IP to URL

Testing

Do not forget to commit your changes

You may need to restart the GP client

Test web browse to https://globalprotect.domain.com

Test connecting the GP client to globalprotect.domain.com

packet capture on cisco ASA firewall with trace

Good capture option here for ASA

You can do a show trace on it and it goes though it like a packet tracer

capture capout2 type raw-data trace detail interface OUTSIDE include-decrypted match ip host 192.168.10.50 host 8.8.4.4

show capture capout2 trace detail packet-number 1

Palo alto BPA

Log into your palo alto firewall

On Device -> Support 

In the Tech Support File section 

Click generate Tech support file (takes a while)

Then download the tech support file

Log into support web site:

https://support.paloaltonetworks.com/

Will have to login with google authenticator 

Login with your account.

Select the customer account in the top left drop down

On the left hand side go to tools -> Best Practice Assessment

Click on "Generate New BPA" in the top right

Select the downloaded tech support file

Select architecture classfications

Untrust = Internet etc

Don't enable Inline cloud analysis under anti spyware section of BPA, drops traffic but doesn't show in the logs.

test policy on palo alto similar to packet tracer

 I haven't had much luck with this, it doesn't seem to work as well as packet tracer. It's often returning that the traffic is blocked when in fact it is allowed.

Anyway you can give it a go, its down the bottom in the GUI "Test policy match"

On CLI:

test security-policy-match source 192.168.0.1 destination 8.8.8.8 destination-port 53 protocol 17

test security-policy-match source 192.168.0.1 destination 8.8.8.8 destination-port 443 protocol 6

Protocol 17 = udp

Protocol 6 = tcp

https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-cli-quick-start/use-the-cli/test-the-configuration/test-policy-matches

NAT on palo alto firewall

 I find switching from ASA to palo alto NAT confusing because they work in a different way and I've worked on ASA for so long.

nat rule (to nat traffic)

outside -> outside

Destination address is customer public IP: 100.200.200.114

Destination translations address is inside IP of the server: 192.168.0.1

policy rule (to allow traffic)

outside -> inside

Source IP is outside source public 8.8.8.8

inside destination IP is the public IP: 100.200.200.114

The main thing there is a public IP NAT is outside to outside on palo. On ASA its outside to inside for a public IP NAT.

• Source zone: outside
• Destination zone: outside
• Destination interface: eth1/1 (outside)
• Source add: any
• Destination address: 100.100.100.50 (public IP of server)
• Service: port 443
• Source translation: "none"
• Destination Translation:
• destination-translation (translation type "static IP")
• address: 192.168.100.50 (inside IP)
• port: 443

test outbound UDP traffic from citrix netscaler

I needed a way to test outbound UDP traffic from citrix netscaler to prove traffic was working.

Normally I would use telnet for a quick TCP port check or the "nc" command but nc was not available on NetScaler and I could not install. I was able to test like so

Log into citrix netscaller

"shell" to get into CLI mode

echo -n "Test from 192.168.0.10" > /dev/udp/172.30.50.50/514

This sent UDP traffic from 192.168.0.10 (citrix) to 172.30.50.50 (logserver) on UDP port 514 (syslog)

I was able to see it arrive in my wireshark capture on 172.30.50.50

pfsense

pfsense is open source firewall for linux

Can be run on any x86 machine with 2 (preferably intel) NICs 

It can be of interest to business because the company https://www.netgate.com/ creates hardware and can also provide support.

It can also be virtualised in VMware etc.

Sample business 7000 users 

Used pair of Netgate 7100 in HA

Each 7100 costs like $1200 so $2400 for the pair

Put that price up against similar setup from Cisco/Palo/Sonicwall

pfsense is the project

pfsense+ is a product a few hundred bucks a year for a support, can be increase for lower SLA

tnsr is a netgate product for faster routing at datacentre level. pfsense is all GUI, tnsr is all CLI.

Limitations

The main thing its missing the full SSL traffic inspection. It can do it but it doesn't work well. Not many firewalls can do the SSL inspection on

You need to put bypass in for cert pinning like google / paypal etc

How many customers running cisco/palo are actually doing full SSL decryption ?

Can't go bigger than 10gig interface but probably not an issue for the target SME's.

80-100 concurrent VPN users. 

Investigating high CPU usage on cisco ASA

http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/113185-asaperformance.html


http://www.tunnelsup.com/troubleshooting-high-cpu-on-a-cisco-asa

For FTD

show process cpu-usage sorted non-zero

show conn | include .*INSIDE .*DMZ

sh cpu usage

Generate TS file during issues, TAC said its ok to do but seems like it would push your CPU higher maybe there is a separate CPU for TS file generation.

Firepower hotfix and patch schedule info

 When cisco find an issue they sometimes release a hotfix as a small quick fix.

The real fix will be put into the next maintenance release.

6.6 last FMC that supports cisco user agent ID. If you want to go above you need to uninstall useragent and install Cisco ISE-PIC agent

6.7.0 removes support for old ciphers. If you are using FTD you need to make sure all VPNs have been migrated to IKEv2 and updated ciphers.

ASA55xx-X devices only support up to certain sensor patches at time of writing 6.6.5.2

When you upgrade to 6.7.0 for example you should also upgrade to the latest release of 6.7.x at the time of writing it was 6.7.3 this ensures you get all fixes in your branch.

Because branches are worked on by different dev teams just because its fixed in 6.4.0.14 does not mean the same issue is fixed in 6.7.0 so you need to make sure to go to 6.7.3 or what ever is that latest patch in that branch

show patch history on FMC CLI

 SSH to FMC

expert

cat /etc/sf/patch_history

This is useful for seeing hotfixes applied as they don't show in the version number in the web interface

FTD syslog event list

 https://www.cisco.com/c/en/us/td/docs/security/asa/syslog/b_syslog/syslogs1.html?bookSearch=true

show all NAT's for a public IP on palo alto firewall CLI

 show session all filter nat destination | match 100.200.200.10

Get firepower sensor (sfr) details from ASA CLI

Gives sensor IP and manager IP (FMC)

show modules sfr detail