Observation of traffic from a Windows Server 2019 instance with a firewall restricting its egress, and a CloudWatch exercise in filtering and aggregation
Routine Test
At Chaser, we routinely test a variety of real-world setups through the DiscrimiNAT Firewall. It helps keep on top of implementation subtleties by different vendors and identify any regressions early as we improve the product.
FQDN filter for Windows on AWS egress, shall we?
So we fire up the latest and greatest Windows this time, with outbound allowed to 0.0.0.0/0 on all ports.
These observations were made on deploying a Microsoft Windows Server 2019 Base instance with AMI ID ami-023b643326f4d6eff in the eu-west-2 region of AWS.
Flow Logs
In our setup where no DiscrimiNAT specific outbound rules existed in the Security Groups attached to this instance, we observed 132 disallowed connections in the 20 minutes of life it had. We were expecting it to phone home a fair bit. So no surprises there.
Query Used: stats count()
Breaking it down by destination hostnames, we get our first glimpse into the various services it's trying to connect to.
Query Used: stats count() by dhost
Interesting that 53 times, the dhost field was empty. We wonder what's going on there...
Query Used: filter ! ispresent(dhost) | stats count() by proto,dpt
Well, port 80 is easily explained – plaintext HTTP connections most likely. Since we don't implement a plaintext parser, the dhost field comes out empty. However, dhost absent when the protocol is TLS is unexpected. SNI has been standard for so many years, so we decide to dig in a bit deeper.
Query Used: filter ! ispresent(dhost) | stats count() by proto,dpt,proto_v
SSLv3?
No!
We are in denial at this stage.
- Is this a bug in our TLS parser?
- Merely a logging issue?
- Windows XP?
Trying Hard
Query Used: {$.dst = 40.90.137.125}
It would appear the firewall is working as expected, but Windows is attempting with a lower version of TLS in case a connection attempt fails. And it goes all the way down to SSLv3! This cycle occurs a few times during our test.
Not Always
Query Used: {$.dst = "13.74.179.117"}
In the case of hostname sls.update.microsoft.com, that doesn't appear to be the case. It stays at TLS 1.2. A disparate but welcome behaviour!
More Questions
We know Windows carries a lot of baggage, but one can't help wonder if this can be exploited by deliberately inducing a network issue, externally manifested. Also, the difference in the behaviour of perhaps various subsystems within Windows hints of long-forgotten tech debt.
We hope you enjoyed this CloudWatch exercise in filtering, armed now with the knowledge that a modern firewall can prevent a lot of undesirable behaviour emanating from programs we trust to run in the Cloud.
Do watch our 2-minute demo on how DiscrimiNAT integrates with Security Groups on AWS.