FTD FMC best practice ACP

Hello Community,

I’m currently the defacto guy forsevaral school districts, we were hit by ransomware. TA got in on the VPN, I was ignorant in the ACP being able to stop the VPN access, I figured block geo hish risk areas was good enough, nope. Lessons learned, Russia done encrypted my entire infra and any online workstations. Was able to recover after a hail Mary on my ancient San setup.

I’ve done a lot of reading and learning since the recovery, and I am feeling a lot better about my knowledge base.

Did some searches, found NSA hardening guide, CISA hardening, all sorts of random security hardening guidelines.

I’m just trying to get some advice from the community about what sort ACP rules they have in place.

I’ve implemented centralized syslog, MFA via Duo SAML for VPN, upping to security over connectivity and creating allow rules when people start screaming “it’s broke!”

If anyone in the K12 sector could share the general idealogy behind their FTD configs, I would appreciate it and any general networking “do this, be better” tips.

For reference I’m on FMC 1600 and FTD 2110 running 7.2.4, with a 3750x acting as the router and a 4507r+e acting as the core for a bunch of 3850s. All running the recommended IOS. (All static routes and only the 4507r+e doing L3 internally)

Fyi. Geoblocking does not apply to VPN. VPN connections are TO the FTD, not through the FTD. (Same for ASA) It is being worked on… look at trusted endpoints and DAP to further filter what systems can connect to the VPN

That said, geo blocking does cut down on the amount of traffic systems behind the FTD have to deal with.

Snort 3 if you didn’t already do that upgrade.

Upgrade to 7.2.5.1 to get the VPN vulnerability fixes as well.

Also, from your post, we have no idea (at least not fully) how the malware was initially introduced to the environment. You say through VPN, was it compromised creds, an already infected machine, what did the processes do? Etc. All of your comments are good things to do, but you need a full incident response investigation to understand what happened, how it spread, how it operates, what systems it touched, etc before you can intelligently start worrying about how to prevent the same attack in the future.

If possible, I’d look at moving the services you can to SaaS so that you limit the risk from a “one man shop” cyber security program. I start with what changes can be made to reduce/eliminate the need for the VPN, and I’d try to move the organization to Zero Trust framework/architecture.

Keep in mind that the FTD is also limited in what it can do when sessions are encrypted, and implementing SSL known-cert decryption for your services will help stop attacks that are concealed within encrypted sessions e.g., SQL injection against a web service.

Last but not least, while geo restrictions are nice, threat actors today use anonymous proxies and other tactics to ensure their attacks source from within the US. As such, while they are important to have, their value is diminishing.

I’d bet big bucks the vulnerability they exploited was a crap password. All that stuff is good but passwords are critical and TAs are password spraying the crap out of vpn login pages now

FTD should have control plane ACL to block foreign IPs to the VPN. Hopefully they now have MFA

Yes, I was a dumb dumb, just inherited the system and when I did my initial overview to start documenting everything, had made an improper assumption there. I definitely learned my lesson. I do have trusted endpoints from the Duo side, and DAP in place now for the RA sessions.

I’m snorting to third now as well.

Hooray! Is it bad practice to ship it in the middle of the work day? (/s)

Also, I swear, the software notifications do not work. This was released on November 14th, and I received no email. “My Notifications” on software.cisco.com is a lie!

That portion was covered by cyber liability, I was just giving a brief overview to draw the picture of my motivation to do better and get some examples/explanation of the ideology behind someone else’s ACP. I will share a little bit more about the how anyway;

There was “malware” (see scripts, memory dumps, etc that easily exploited a poorly secured AD environment) and that TA entry finder likely sold to a popular ransomware group. The investigation report declared initial entry by exploiting the vulnerability in the FTD. See CVE-2023-20269, this likely was not terribly difficult to exploit, due to poor configuration and a poor password policy with even crummier tiering on AD access.

I’ve made a lot of changes I should have made day 1, but get to make now and develop better standard operating procedures, cyber response plans, etc. (LAPS, least privilege, Purple Knight was my friend and PDQ I/d helped me to make rapid changes)

My boss at the time of my hire wanted me to maintain the status quo and not implement drastic changes, so I did what I could to request “Our password policy is garbage, can I change it?” “No, I don’t want to deal with tickets getting people locked out” - They did let me buy Nessus and Duo, but didn’t let me just roll Duo out environment wide for Microsoft logins. Even after a month long and successful trial run. They didn’t let me put it on the servers, and they went in duo admin and set up a bypass for their DA account because they liked to log on to their work station with those credentials and couldn’t be bothered. Shudders. You say “That’s dumb” to someone who has been “doing this way longer than you” and they will ostrich even harder.

There is an understandable friction when change is mentioned to people that have just been going with tradition. I’m very much of the mindset, let me utilize this device/service I’m paying for fully, understand best practices for it, and implement those best practices per my need and capabilities. When it breaks stuff, take accountability, curse random engineers and capitalism, and fix it.

Rant aside, I’ve read a lot of best practice guides for FMC/FTD and am just looking to connect best practice and practical given my resources.

Block as the suggested default action from the NSA seems like a gargantuan undertaking which I’m severely understaffed to support a simple transition to.

I’ve thought about collating logs and scripting a solution to examine the traffic, make a million and 2 rules in the ACP, and go with the default action of block. I just fear that it would be incredibly difficult for me to implement with minimum friction. Maybe someone has done something like this and knows some magic resources that I could investigate and execute on.

I’ve started adding allow from inbound to outbound with a less extensive intrusion policy for known IP blocks, Google servers, apple servers, Microsoft update servers, etc to lessen the strain and having a more aggressive intrusion policy on the inbound outbound allow rules at the end of my ACP. This rule creates a lot of false positives, but it has saved me in conjunction with my mdr of a few client machines trying to hit a known CnC.

I really just wish I could hop on, and chat with a peer and have them explain their ACP. Monkey see, monkey do. I asked here hoping someone might have a redacted SS, but I do understand it’s the equivalent of “Hey show me your dirty underwear”

You can do it by IPs, but not by countries, if that makes sense. The countries code is Snort, and control plane isn’t protected by Snort.

Another gotcha here is this is a patch so you need to be in 7.2.5 first to get there.

You may want to check the frequency of your email notification and the train it’s set to it tends to be version specific.

Create some ACLs that cover the most common stuff like 80/443 and below that put your permit any if you can’t do a deny all. This way the 80/443 is logging on a different rule and you can track what else hits the rule below it. You might be surprised how little other access your users actually need.

Sorry, I was implying it can be done manually without saying that.

This is the joys you find of the bastard child of ASA and Sourcefire code working together as one box.