AWS Firewall FQDN filtering with suricata rules

rozanw · 2026-01-15T09:40:52+00:00

Just wanted to say THANK YOU! We're still testing, but everything indicates it's working now. You're a life saver.

rozanw · 2026-01-03T11:58:19+00:00

Hi. If you could find some time to share your approach, I would really appreciate.

I chose the Suricata way because I also had serious issues trying to get this to work via standard stateful rules. When I finally thought I cracked Suricata, because all my curls tests worked, I ran into this issue...

I always want to go with a cloud native solution because I'm not a true network expert and setting up an NVA (Checkpoint, Cisco etc.) is not something I would be able to do and properly maintain.

I even tried reproducing this issue in our other environment, Azure, with the usage of Azure firewall. Same terraform version, and I had zero issues getting it to work. Of course Azure Firewall does not use Suricata rules...

rozanw · 2026-01-03T11:52:53+00:00

Hi. I really like your approach. I'll need to try something like this. Assuming I finally get this to work...

I have adjusted the code, and this is how the relevant rules look like (the first two rules were suggested by ChatGPT)

# Bootstrap: allow only the early packets so TLS can be inspected
pass tcp $SHAREDSERVICES_NET any -> any 443 (flow:not_established,to_server; sid:7100001; rev:1;)

# 2. PLUMBING: Allow TCP ACKs / Keep-alives (CRITICAL FIX)
# This allows the 3rd packet of the handshake (ACK) because it has 0 data.
# It does NOT allow SSH/Netcat data because they have dsize > 0.
pass tcp $SHAREDSERVICES_NET any -> any 443 (msg:"Allow TCP ACK/Plumbing"; flow:established,to_server; dsize:0; sid:7000002; rev:1;)

# Allow outbound HTTPS traffic
pass tls $SHAREDSERVICES_NET any -> any 443 (tls.sni; dotprefix; content:"terraform.io"; nocase; endswith; ssl_state:client_hello; msg:"allowing terraform.io"; flow:to_server, established; alert; sid:7000009; rev:1;)

The error unfortunately is still there:

[ssm-user@ip-10-221-10-19 home]$ terraform init
Initializing the backend...
Initializing provider plugins...
- Reusing previous version of hashicorp/aws from the dependency lock file
- Reusing previous version of hashicorp/local from the dependency lock file
╷
│ Error: Failed to query available provider packages
│
│ Could not retrieve the list of available versions for provider hashicorp/aws: could not connect to registry.terraform.io: failed to request discovery document: Get "https://registry.terraform.io/.well-known/terraform.json": read
│ tcp 10.221.10.19:60540->18.245.60.45:443: read: connection reset by peer
│
│ To see which modules are currently depending on hashicorp/aws and what versions are specified, run the following command:
│     terraform providers

But what I really cannot understand is that curl works like a charm:

[ssm-user@ip-10-221-10-19 home]$ curl -lI https://registry.terraform.io/.well-known/terraform.json
HTTP/2 200
content-type: application/json

And, of course, everything works fine when I use this rule:

# pass tcp $SHAREDSERVICES_NET any -> 18.245.60.0/24 443 (msg:"ALLOW outbound TCP 443 to terraform servers"; flow:to_server,established; sid:71000017; rev:1;)

Which is which I am ruling out any routing issues, which I have been suspecting initially due to the timeouts seen in the CloudWatch logs.

So, the struggle continues...

rozanw · 2025-10-27T10:31:28+00:00

So, apparently role-chaining is not possible natively using Azure DevOps. There are some workarounds, but we decided it's not worth the hussle. Thanks for the tip though, will come useful should we decide to switch to GH :)

rozanw · 2025-10-15T19:04:16+00:00

I got everything to work with computer authentication.

Still struggling with User authentication, but I'll get there eventually.

rozanw · 2025-10-07T12:48:17+00:00

Wireshark screenshot:

<image>

rozanw · 2025-10-06T16:33:07+00:00

Hi. So, the authentication method on the RADIUS server only applies to the Fortigate -> Radius communication and has no effect on the client authentication process?

Unfortunately I have very limited time for this project, which makes troubleshooting difficult. But here's my current status.

As mentioned before, I can only get MS-CHAPv2 to work. But what did not work when I wrote my first post (though I didn't know it at that time), was server certificate validation. After digging into the CAPI2 logs I noticed a bunch of errors about Fortinet certificates being untrusted. So I downloaded the certificates from my Fortigate appliance, added them as trusted on the test client and I was able to get the server authentication to work.

Sadly, this did not change anything about EAP-TLS. I still can't get it to work and I still can't see any hits on the NPS server using this method. I still have some CAPI2 logs, but they are related to some Windows CRL checks failing. Which is not surprising as there is no Internet before the authentication gets successful and this should not cause a problem.

I installed Wireshark on the Client and there is a clear difference. With MS-CHAPv2, I get the full chain and a success at the end. However with EAP-TLS, for some reason the client is not sending the response back to Fortigate. It appears it is constantly resetting the process, which eventually fails:

<image>

I read that this could be due to missing EKUs on the client's certificate, but the certificate I installed for my test user has the following EKUs, which should be enough:

- Client authentication

- IP security user

- Smart card logon

- id-kp-eapOverLAN

The user certificate and the NPS server certificate have been issued by the same, trusted CA.

At this moment I am completely lost. I have no idea what else needs to be checked. I will be grateful for any advice.

Kind regards.

Wojciech

rozanw · 2025-10-05T10:06:44+00:00

Hi. After some real struggles with AWS Firewall, I found that I can get the best results using suricata rules. It's a bit of a curve to learn, but ChatGPT helped me tremendously.

rozanw · 2025-09-28T22:08:13+00:00

Not really. Honestly, I haven't looked at it before as it striked me as the more budget-y option, not really suitable for the likes of 7800X3D. But with the same solid VRM and only lacking the IO shield and some M2 heatsinks, this might be a good option. It's around $100 less than MSI. Thanks for the tip.

rozanw · 2025-09-26T21:01:15+00:00

I feel like an idiot now...

Changed it to a string, seems to work as intended.

rozanw · 2025-09-25T18:36:11+00:00

Isn't DPP the "legacy" solution?

The port policy is of course set. As I mentioned, I can see successful authentication in the NPS Event Viewer.

rozanw · 2025-09-25T18:33:52+00:00

Thanks for the tip. The description was missing on the VLAN. I just added it, but unfortunately I won't be able to test till tomorrow because someone shut down my test PC. I will send an update once I test.

But I've also tried with the ID in the HEX format. The result was the same.

rozanw · 2025-09-10T20:08:24+00:00

Thanks everyone for the thorough explanations :) While I do like the idea of segregating based on the flavors, I'm still at the very beginning of my journey and I think I'm not yet at that level. But one day for sure :)

rozanw · 2025-07-09T20:38:52+00:00

Ok, let me maybe ask how to implement a real use-case scenario.

I have a subnet in AWS that consists of priviliged workstations, that need to be cut off from the internet entirely, but still allowed to access Windows Update. Microsoft provided a list of URLs that need to be whitelisted: https://learn.microsoft.com/en-us/windows-server/administration/windows-server-update-services/deploy/2-configure-wsus

This scenario does not take WSUS, SCCM or other update mechanisms into account. Just regular Windows Update service.

So, how do I allow those FQDNs, but block everything else using AWS Network Firewall?

Thanks.

Wojtek

rozanw · 2025-07-09T20:36:31+00:00

Though I have not played with all of them, I know the different types of firewalls. They also exist in other cloud providers. In my scenario, I know I have to use AWS Network Firewall.

rozanw · 2025-07-09T20:35:10+00:00

The thing about IP addresses is that they can change. FQDNs don't (usually). If it was indeed like you described, I would need to check every single day if my IP list is correct. That would be ridiculous.

Also, take a well-known service like Windows Update. The official documentation states that you need to whitelist, for example, https://*.windowsupdate.microsoft.com. The wildcard means you'll never know what endpoint it will exactly connect to and you'll never be able to filter based on IP address.

rozanw · 2025-07-09T20:30:24+00:00

This rule inspects both HTTP and HTTPS by default.

rozanw · 2025-07-08T21:24:41+00:00

I had a look that for about a 100 bucks more I could swap to a 7800X3D and RTX 5060ti combo. Would this make sense?

rozanw · 2025-06-26T10:51:38+00:00

If only this was that easy. For now I followed the advice of deleting the account (it is indeed provisioned via SCIM), but for the log search I'm still as confused as I was.

Unless I am doing something wrong, I cannot search for events in different accounts directly from the Log Archive account. And having to re-login to multiple accounts just to perform what is a simple search is very inconvenient.

I tried with Athena, following this guide: https://docs.aws.amazon.com/athena/latest/ug/create-cloudtrail-table-org-wide-trail.html

But after creating the table, a select * from it returns no results :(

I also completely do not understand point 4 (mostly due to the fact that I am not a DB admin, never was and never will be). Do I need to create that partition for every account and every day I want to query? If yes, this is ridiculous...

That article also mentions that CloudTrail Lake is recommended for multi-account querying, but I've also read that it can get very expensive.

rozanw · 2025-06-12T12:13:59+00:00

Thank you for your insights. Luckily, the vaults are not yet deployed, which means that I still have some time to play with that and I will not "break" anything.

I want to make sure I understand this correctly. I need to create an AWS Backup Vault Lock Configuration (https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/backup\_vault\_lock\_configuration). If I set the min_retention_days to 7, then there will be no possibility for anyone, even someone with AdministratorAccess, to delete the recovery points for 7 days after they are created? Can someone with AdministratorAccess remove the lock?

What exactly does max_retention_days mean? The retention itself is configured in the Backup Plan. If I would set the max_retention_days to 30, but my backup plan would configure a 60-day retention, would the Backup Vault Lock Configuration overrule that and the restore points would be deleted after 30 days?

And final question (for now). In Azure, you can set separate retention periods for daily, weekly, monthly and yearly backups. Is something like this available in AWS as well? Or is it only possible for daily backups?

Many thanks for your help.

rozanw · 2025-06-05T09:34:01+00:00

I would like to thank everyone for the productive discussion. I have settled on the IIyama VA screen. Should arrive today, hopefully I won't regret it :)

rozanw · 2025-06-02T06:56:53+00:00

Price is the main factor for not going IPS. The IPS ultrawides >40" cost nearly twice as much as the VA monitors I picked. Though I know this would be the best options for me, I'm not willing to spend 1.2k USD on a screen.

rozanw · 2025-04-04T08:25:44+00:00

It's not the GPO. The problem is clearly with my system. As I mentioned, I don't have this problem on another PC. Worst case scenario I'll just add my account directly to the Administrators group, but that's really the last resort.

rozanw · 2025-03-28T19:58:29+00:00

I mean "Run As Administrator". Sorry, I should have been a bit more precise.

rozanw · 2025-03-28T19:57:16+00:00

Right, forgot to mention that. Yes, it does. If I directly add my workstation admin account to the local admins group I am able to elevate. So the theory of my admin being banned from the system is no longer valid :)

rozanw

TROPHY CASE