They are sending it now as a stream so it seems not to be closed.
Try this in RAW and see if that stops the attacks:
psd (integer,time,integer,integer; Default: ) Attempts to detect TCP and UDP scans. Parameters are in following format WeightThreshold, DelayThreshold, LowPortWeight, HighPortWeight
WeightThreshold - total weight of the latest TCP/UDP packets with different destination ports coming from the same host to be treated as port scan sequence
DelayThreshold - delay for the packets with different destination ports coming from the same host to be treated as possible port scan subsequence
LowPortWeight - weight of the packets with privileged (<1024) destination port
HighPortWeight - weight of the packet with non-priviliged destination port
I still want users with a valid certificate to connect, so just closing port 1194 is not really an option. Moving to port 1196 for example is just a matter of time..
Problem is the source IP + source port remain the same.
Don’t think the PSD attributed are going to be very useful here…they operate on the DESTINATION PORT and (same) SOURCE-IP but does not look at the SRC-PORT of the SOURCE-IP.
If your OpenVPN needs to be really … open and globally accessible I think the options are limited …
Ask yourself : Does the whole world need potential access to it ? If you live in country X why not limit access to IP’s of country X … I don’t know your exact use-case for OpenVPN.
Hey.. Actually, yes, all over the world. Users connecting to my VPN can watch Yelo TV outside Europe..
I have customers in Dubai, Thailand, USA and few other countries..
That is the issue with running a full public service…
Off course I don’t know your userbase, but perhaps a script before the connection could be launch to trigger a port-knock sequence effectively open up OpenVPN ports…however you need to discuss with your users.
I don’t know who managed the clients, on which platforms they run etc,etc.
That’s the point why I use OpenVPN. My customers aren’t that computer-minded, so importing a certificate, inputting username and password is just doable for them. If i talk them about port-knocking they probably go knock on their own ‘gate’.
So what you’re saying is: deal with it, not really a solution?
Ah OK, a (semi) illegal service then since I don’t think Telenet allows this
There is a reason why this (live) content-viewing is limited within EU…
Anyway for your problem I think you just need to deal with it
Invest time to scan the logs regularly, do some parsing and add the annoying guys onto the block-list anyway and hope it goes away quickly.
If your backend systems/OpenVPN gateway are sized appropriately it will handle it and not get stressed out by these (few) attempts.
The IP spamming you is registered Saudi Telecom apparently…
Perhaps the solution given earlier might help ? The section on SSH-brute force.
If you construct something like that…normally a GOOD user makes an inbound connection (incoming SYN) only once basically. So with a multi-stage filter you can throw the IP’s on the list that make 3 attempts or something. Only the “state” is evaluated and normally from the same IP you don’t want to see 3 SYN’s coming in.
But perhaps you should take a capture to have slighty more details on what they are injecting, but I suppose at TCP-level the 3-way handshake works because I seen the OpenVPN service create some channel?
They’re Belgian citizens with a valid telenet login..
The annoying guys are automatically put on a blacklist and blocked.. That stops about 90% (316 different IP’s in 24h) The only difficutly I’m facing now is when the originating port is the same, then they can have indefinite attempts. It’s not stressed, nobody complaining about poor quality..
Yes, i already traced some of the IP’s. The Saudi’s and the Russians are very active.. If of course, the IP’s are not spoofed..
Why would udp scans be stopped by a TCP rule (title of thread- “FLOODING UDP”)??
"A port scanner was actually alreadt active in the firewall / filter:
add action=add-src-to-address-list address-list=blocked-addr address-list-timeout=1w chain=input comment=“Port Scanner Detect**” protocol=tcp** psd=
21,3s,3,1
So far it blocked 1 ip-address.."e
Perhaps you should review your “psd” attributes, by default they are 21,3s,3,1 but they need tuning
I would evaluate over a larger time-window.
I evaluate over the span of multiple hours, my “total weight” (default 21) has been brought down also and then weight for low-ports-hits (3) and high-port-hits (1) also adjusted.
total weight = amount of hits x weight-per-type.
You can play with that.
This means over a span of 4 hours, the “attacker” would be allowed to fire 6 packets targeted at a low port (< 1024) because then he reaches 6 x 3 = 18 and this exceeds the total-weight 15 threshold.
Similar an attacker could fire 16 packets at a high-port, so 16 x 1 = 16 and also exceeds total-weight of 15.
See?
@TaxiPieter, your method is doomed to fail.
If your VPN server is on a server or serverPC, then you better should install a tool like fail2ban on that server. See https://en.wikipedia.org/wiki/Fail2ban
And: just remove UDP from VPN, ie. allow only TCP connections… See also https://proprivacy.com/vpn/guides/openvpn-tcp-vs-udp-difference-choose
If you want your OpenVPN server to listen on a TCP port instead of a UDP port, use proto tcp instead of proto udp in its config file.
Then you can block incoming traffic to the UDP port 1194 completely.
