Any request to other than my.domain.com, including requests to an IP address, will look in /var/www/dummy (which can be empty), because any unrecognized host defaults to the first entry.
Lots of virtual hosts at *:80 will also answer ip connections willy-nilly, a chain of failures until a url match is made or not is not a good thing, please revisit how apache reacts to a connection and what is already leaked if you 301 http to https (which is highly recommended in 2023 and above) look at your http servers logs for clues , not as common as udp/5060 and only from the clever buggers.
The :80 I posted was just an example; the OP is using port 1220, which will eliminate nearly all the noise traffic. Of course, taking the ‘dummy’ path ensures that a URL match will not occur.
IMO, there is no reason to have HTTP accessible to the outside world at all – end users should always use HTTPS. The most recent browsers will default to HTTPS if no protocol is specified. For users with older browsers, they may have to type https:// once, IMO a trivial inconvenience. However, IMO enabling HTTP access from localhost is a good idea; if something goes wrong with HTTPS, the sysadmin can use SSH port forwarding to access the GUI via HTTP.
I won’t disagree with any of that, I posit that my solution above solves all those problems and more in a far more efficient manner, if you can complete a journey in one step, then any other route should be questioned.
I would point out that the all services should remain as http if you want to tunnel and further you don’t need to eff with certs and firewall pin holes for them.
As I said, if you are talking about HTTP, if there is no domain name there may be no character representation of the IP address; they may be using an HTTP 1.0 request, which doesn’t have a Host header.
The above example results in all TCP traffic on port 1220 getting dropped.
The expected result of the above example is to drop all TCP traffic on 1220 except for traffic with “my.domain.com” string match.
You might want to note that the string match rule requires the match to occur within a single packet, and only applies to that packet (the firewall doesn’t duplicate TCP). For example, if you white list the domain and someone does a long POST (or even a GET with lots of parameters), at most one packet will match.
On the basis that a re-used connection will be from the the same source, assuming GET requests aren’t excessive, matching the first packet may be enough, assuming there is a rule for that.
Also, note that, if you are using HTTPS, any clear text domain name will be put there by TLS, not by HTTP, so the precise details of the use of Host header won’t apply. I thought this was normally always done using TLS.
This approach feels like driving in a nail with a wrench. I think you’re using the wrong tools. Can you back up to the beginning and explain why you’re trying to filter like this?
The heart of the solution I am after is to not have my server respond to port sniffing and subsequent naughty activity that arrive at the server via the server’s IP address.
The war pings I am seeing & the subsequent attack is landing at the server via the servers IP address.
The FQDN is seeing no naughty inbound traffic.
Therefore I want to block traffic on certain ports that arrive via the servers IP address, and allow traffic that arrives at the same ports via the FQDN.
To what ‘port sniffing’ is your server responding to?
What ‘naughty activity’ have you seen ?
Because as @billsimon suggested, iptables might not be the right tool to ‘stiffen up’ your services.
You won’t be able to look inside OpenVPN packets for strings, as as they are encrypted. I don’t see how you can be matching domain names, as OpenVPN doesn’t send them for its own use.
For most protocols, the originator looks up domain names using DNS, and then only sends the IP address. This also used to be the case for HTTP, but people started running multiple servers on the same IP address.