Pass tcp traffic based on dns instead of ip address

I am trying out Suricata rules within AWS network firewall. I am trying to pass a tcp rule by providing a domain name instead of ip address. Reason being ip address can often change. Also DNS may be mapped to multiple ips. Is this even possible like in http or https? I understand its encrypted and cannot be parsed at network layer however want to check if there is any workaround other then getting ip mapped to dns and modify the rule.

pass tcp $HOME_NET any → <any_domain_name> $ALLOW_PORTS(msg:“Allow TCP 22”; sid:172192; priority:1; rev:1;)

Above does not work.

Below works fine

pass tcp $HOME_NET any → $VAL_IP $ALLOW_PORTS(msg:“Allow TCP 22”; sid:172192; priority:1; rev:1;)

$VAL_IP lists all possible IPs

This won’t work, since the variables for that part can only include IPs.

Depending on the type of traffic you could try to use flowbits. So you use tls_sni for example to match against the domain and set the flowbit and afterwards you also have a pass rule that also matches on that set flowbit.
You could also try to play around with datasets.
You need to find a way to have an indicator at the beginning of the flow. Using the DNS query doesn’t help since this would be a different flow for the actual traffic afterwards.

In theory you could also dynamically update the $VAL_IP with an external script to resolve the IPs and add those to this list and trigger a rule-reload to enable the new value. But in a fast paced changing DNS record that won’t help either.

But maybe someone else has a better idea.

Thanks a lot Andreas, Its for ssh traffic. Is there an option to use tls_sni for ssh traffic. I have seen it being used for http/https. Appreciate your feedback and help in this regard.

I believe your netmask on the host IP address is incorrect. It is actually invalid for a specific host. Your destination IP should be if meant to define a single specific host. The “/0” CIDR mask indicates all possible addresses in the universe. So your PASS rule is going to allow an SSH connection (port 22) to any host IP. And once traffic matches a PASS rule, it is evaluated no further.

This sounds like a misunderstanding. The field in the TLS protocol that the tls_sni keyword uses does not exist in SSH.