3 ms·

Does the AWS EC2 network filters UDP packets with a spoofed source? Is the firewall well configured? Because it sounds like something spamming UDP packets wit

Does the AWS EC2 network filters UDP packets with a spoofed source? Is the firewall well configured? Because it sounds like something spamming UDP packets with IP spoofing could take down all kubernetes nodes. Maybe signing the kernel panic message could help too.

vlovich123 3y ago
> Luckily the netconsole-setup command makes the setup pretty easy. All the configuration options can be set dynamically as well, so that when the endpoint changes one can point to the new IP. There’s no spoofing happening here…
- wrs 3y ago
  Yes, but what if there was? A safer alternative would be to simply do the annotation and leave k8s to do the deletes on timeout as usual.
- dafelst 3y ago
  I think OP is highlighting that spamming spoofed UDP packets to this service is an attack vector for a denial of service attack.
  - dastbe 3y ago
    in that case, yes aws ec2 (and other cloud providers) disable ip spoofing by default for VMs in your VPC.
    - speedgoose 3y ago
      Thanks. That’s a good feature from AWS.
alexeldeib 3y ago
From the description, I’d think this is all in cluster, not public.
nonameiguess 3y ago
If you mean traffic from outside of the cluster, there is no reason for their cluster nodes to have public IP addresses, so they wouldn't even be routable from outside the VPC. I would expect this controller to run on the control plane and probably not be Internet-accessible by any means, but even if it were, I'm sure the security group only allows UDP port 6666 from inside the cluster, presumably based on source security group, not IP, so even if you could somehow spoof a private IP address and get it into the VPC, it would still not be accepted. If you mean malicious traffic coming from their own pods, they could simply add Kubernetes network policies not allowing UDP port 6666 egress from any pod since the traffic they're actually hoping for would always come from a kernel, not a pod, and thus egress from a different interface. So now you're left with the remaining attack vectors being spoofed IPs, or potentially even the correct IP but a spoofed packet, coming directly from EC2 instances in the same VPC, either by launching separate instances or compromising clusters nodes at the OS level. An insider with that level of access is always a threat pretty much no matter what you do because they could just delete your nodes through the EC2 service. You mitigate that with thorough audit logging, no shared or long-lived credentials, deep vetting of a very small number of personnel you give that level of access to, and the threat of near-certain jail time if someone does it on purpose anyway.

vlovich123 3y ago

> Luckily the netconsole-setup command makes the setup pretty easy. All the configuration options can be set dynamically as well, so that when the endpoint changes one can point to the new IP. There’s no spoofing happening here…

wrs 3y ago
Yes, but what if there was? A safer alternative would be to simply do the annotation and leave k8s to do the deletes on timeout as usual.
dafelst 3y ago
I think OP is highlighting that spamming spoofed UDP packets to this service is an attack vector for a denial of service attack.
- dastbe 3y ago
  in that case, yes aws ec2 (and other cloud providers) disable ip spoofing by default for VMs in your VPC.
  - speedgoose 3y ago
    Thanks. That’s a good feature from AWS.

alexeldeib 3y ago

From the description, I’d think this is all in cluster, not public.

nonameiguess 3y ago

If you mean traffic from outside of the cluster, there is no reason for their cluster nodes to have public IP addresses, so they wouldn't even be routable from outside the VPC. I would expect this controller to run on the control plane and probably not be Internet-accessible by any means, but even if it were, I'm sure the security group only allows UDP port 6666 from inside the cluster, presumably based on source security group, not IP, so even if you could somehow spoof a private IP address and get it into the VPC, it would still not be accepted. If you mean malicious traffic coming from their own pods, they could simply add Kubernetes network policies not allowing UDP port 6666 egress from any pod since the traffic they're actually hoping for would always come from a kernel, not a pod, and thus egress from a different interface. So now you're left with the remaining attack vectors being spoofed IPs, or potentially even the correct IP but a spoofed packet, coming directly from EC2 instances in the same VPC, either by launching separate instances or compromising clusters nodes at the OS level. An insider with that level of access is always a threat pretty much no matter what you do because they could just delete your nodes through the EC2 service. You mitigate that with thorough audit logging, no shared or long-lived credentials, deep vetting of a very small number of personnel you give that level of access to, and the threat of near-certain jail time if someone does it on purpose anyway.