2

I have a PBX (phone system called Astersik) that works with udp and tcp. Sometimes I get invalid request from some IP addresses that I will like to block. I cannot block those requests until I reboot my computer. I think the reason is because UFW will not block established connections.

Let's pretend I am getting malicious request from the ip address 1.2.3.4. I then need to block those request by executing the command:

sudo ufw insert 1 deny from 1.2.3.4 to any

I need the insert 1 so that the rule is executed before the other ones.

Anyways even though I execute that command I still see that my computer replies back to 1.2.3.4. The problem is because there is already an establish connection therefore ufw will not drop those packets until those connections are closed.

I found a temporary solution:

1) I open nano /etc/ufw/before.rules

2) Comment the lines:

enter image description here

(In the picture the lines are not commented. But comment everything that is inside the red circle)

3) Restart firewall ufw disable then ufw enable

If I comment those lines then my firewall will work like I want. It will block connections right away!

The problem is that commenting those lines causes my dns to stop working In other words now when I execute ping google.com I see uknown host google.com

Why dns stops working when I comment those lines? In short I need that when I execute sudo ufw insert 1 deny from 1.2.3.4 to any I get no more requests from that IP!. I cannot afford to reboot the computer every time I want to block an ip address.

Tono Nam
  • 322

2 Answers2

4

Tono,

ufw is a front end for iptables. What you are asking essentially, is why does DNS fail when you stop accepting Related,Established connections. conntrack keeps track of your connections. If traffic matches an entry in conntrack then it is Established. If an Established connection creates a new connection then it is Related. If the traffic is new and is not Established or Related then it is New.

If there is already an established connection you need to insert a drop instruction at the beginning of the chain. Edit /etc/ufw/before.rules so you have a block section before the rules you commented. Add an entry of -A ufw-before-input -s 1.2.3.4 -j DROP there. Then use sudo ufw reload.

If you still have problems with that think about using iptables instead of ufw because ufw is a front end for iptables and does not include all of its selections.

https://www.cyberciti.biz/faq/how-to-block-an-ip-address-with-ufw-on-ubuntu-linux-server/

https://help.ubuntu.com/community/UFW

https://askubuntu.com/questions/602176/configure-ufw-to-allow-only-established-and-related-conections-on-ipv4

enter link description here

Community
  • 1
user5870571
  • 3,250
2

UDP is a stateless protocol, but the Linux kernel still tracks IP and port numbers for it for 30 seconds, to determine established and related traffic. (30 seconds or the value in /proc/sys/net/netfilter/nf_conntrack_udp_timeout) - ServerFault link: Iptables: "-p udp --state ESTABLISHED"

DNS works over UDP, so if you send out a DNS query, and you have commented out the rule allowing related return traffic, you won't get any reply -> broken DNS.

Because UDP 'state' is tracked for 30 seconds, your attempt to insert a new block rule at the top of INPUT doesn't have any effect. "ufw-before-input" happens first and allows the ESTABLISHED traffic, before your INPUT rule gets to see it and DROP it.

To fix it you either need to:

  • Use something like 'conntrack' to remove the tracked UDP entry for the host you want to block, then add the block rule to the firewall. There won't be an established or related connection, so the block should take immediate effect. e.g. Delete specific conntrack entries?

  • Rework your firewall rules so that you do the ESTABLISHED, RELATED rule in the INPUT rules after your DROPs, instead of doing it first.

I cannot afford to reboot the computer every time I want to block an ip address

But you can afford to filter 4 billion IP addresses, one at a time, blocking them by hand? That doesn't seem a reasonable thing to do. Use an IPS device, use fail2ban.

Community
  • 1
TessellatingHeckler
  • 5,776