Best way to not get run over in the flood of UDP/5060 traffic, is simply choose another transport, you have over 60000 ports and at least three transports that are ‘less traveled’ . but using iptables if you choose a stateful protocol, TCP or TLS will be painfully and with quite some cost as all traffic needs to go through that ‘TSA’ like queue , you can have another ‘process’ filter more dynamically, kinda like a "global entry’ system, which I have posted. That process can be used for all TCP/TLS connections, UDP will always be the wild west because of it’s U
Dicko - are you a bot?
I’m not trying to address 5060. I’m trying to address 1220 (my OVPN port) and do so in the same way as the guy did with 5060
bot test.
Cannot connect to port 80
No, I don’t think so (but I’ll check) , I have been doing this for a couple of years and no longer share your problems 
You said you are using TCP for OpenVPN, so none of that recipe is remotely applicable to you. Further, you have already been told that string matching will not work, so save yourself time and don’t continue on this path…
No. I checked with the wife, she assures me I am not a bot , but I tells me I am definitely a nerd, and it’s time for dinner
3 Likes
Those are two different things. While it is easy to block requests containing your IP address, IMO that is not terribly useful, because the attacker could trivially bypass the block by sending e.g. host: example.com . They may not be doing that now, but if this style of blocking became common, they surely would make the change.
OTOH, allowing only those requests containing your secret obscure domain name provides real security, if the attacker has no way to discover the name. This means that a reverse DNS lookup resolves to an unrelated name, and you don’t have any certificates for that name (certs are public record), but use a suitable wildcard cert instead.
The latter is easy to do in the Apache config, but as @dicko pointed out, some attackers will go through a list of ~150 requests containing various exploits of WordPress, etc. While these are harmless from a security standpoint (they all go to your dummy site), it loads the server and fills the log with junk that may make it harder to see a real threat.
So, it is tempting to block requests without the secret FQDN at the iptables level. This requires first allowing short requests (so the TCP handshake can complete) but specifying NOTRACK. Then, accept a packet with the secret name and allow conntrack to process it, so subsequent traffic on the connection is permitted. Untracked longer not-matching packets are dropped, also with NOTRACK. I’ve not tested this but have seen credible posts describing such methods.
Here is what I have come up with so far. Its still not working so I know I am missing something. This is allowing traffic both with and without the FQDN in the header. I am trying to limit traffic that ONLY has the FQDN in the header.
#start tracking & allow port 1220 on the INPUT
-I INPUT -p tcp --dport 1220 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
#drop all traffic on port 1220 that does not have the FQDN in the string
-A INPUT -p tcp --dport 1220 ! -m string --string “my.domain.com” --algo kmp -j DROP
#allow port 1220 to travel through the output
-P OUTPUT -p tcp --dport 1220 -j ACCEPT
HTTP 1.0 was made obsolete in 1996. So the theory here is that they are using something that Apache/Nginx doesnt do out of the box (HTTP 1.1 is used). Again, just checking that the belief is they are using web server software from 26 years ago.
The attacker would not be using web server software, they would be using web client software. I’m not sure why Apache would reject even HTTP 0.9 requests.
@blaze if there is no host header, then this should DROP traffic, but it is not. If there isn’t a string match, then there isn’t a string match.
-A INPUT -p tcp --dport 1220 ! -m string --string “my.domain.com” --algo kmp -j DROP
what am i missing here?
OK, again we’re talking about a version of HTTP that died around 1996. You’re working theory is 20+ year old version of HTTP, client or not, is being used.
Has anyone actually looked at the packet to see if there is a host header? Or we just positing this is the case?
The OP seems to have switched from HTTP to OpenVPN, so I’d expect it to be all encrypted and unavailable to the firewall.
Im working this solution for both OpenVPN both 1220 and UCP 443.
I figured if I get one port blocking working the way I want I am 2/3 of the way there to get the other port doing the same.
I’m not sure that the domain will be in clear for either HTTPS or OpenVPN. I think it most improbable that it will be for OpenVPN. For HTTPS, I can half imagine circumstances where it would be necessary, but haven’t done to the research to see if it really is sent in clear. If it is, it won’t be a host header.
Whether the domain name is there in encrypted form, for OpenVPN, will depend on the protocol being tunnelled. As I said, historically, most protocols did not send the domain name of the server.
here is what I have tried so far
This first attempt lets all traffic through on port 1220 and does not limit to FQDN based traffic.
#start tracking & allow port 1220 on the INPUT
-I INPUT -p tcp --dport 1220 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
#drop all traffic on port 1220 that does not have the FQDN in the string
-A INPUT -p tcp --dport 1220 ! -m string --string “my.domain.com” --algo kmp -j DROP
#allow port 1220 to travel through the output
-P OUTPUT -p tcp --dport 1220 -j ACCEPT
This second attempt BLOCKS all traffic on port 1220, also not the desired result
Allow for packet which contain my domain name
-A INPUT -i eth0 -p tcp --dport 1220 -m string --string “my.domain.com” --algo bm -j ACCEPT
Block other SIP request like REGISTER INVITE OPTION if they not contain my domain name
-A INPUT -i eth0 -p tcp --dport 1220 ! -m string --string “my.domain.com” --algo bm -j DROP
-A INPUT -i eth0 -p tcp --dport 1220 -m string --string “server IP address” --algo bm -j DROP
Allow to establish TCP connection and other packets then REGISTER INVITE OPTIONS (without domain)
-A INPUT -i eth0 -p tcp --dport 1220 -j ACCEPT
Perhaps you should consider using OpenVPN’s built in methods to require TLS based connections (and thus dropping connections not sent to a domain you have control over)
H,NAB
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.