The relevance of blocking access to prohibited resources affects any administrator who might be officially held accountable for failing to comply with laws or orders from relevant authorities.
Why reinvent the wheel when there are specialized programs and distributions available for our tasks, such as: Zeroshell, pfSense, ClearOS.
Another question arose from management: Does the product we are using have a security certificate from our government?
We have experience working with the mentioned distributions:
- Zeroshell — the developers even gifted us a 2-year license, but it turned out that the distribution we were interested in executed a critical function illogically for us.
- pfSense — respect and honor, yet boring, adapting to the command line of FreeBSD’s firewall wasn’t convenient for us (I think it’s a matter of habit, but it didn’t turn out to be the 'right path').
- ClearOS — it turned out to be very slow on our hardware, and we couldn't reach serious testing, so why bother with such cumbersome interfaces?
- Ideco SELECTA. The product 'Ideco' is a separate conversation, an interesting product, but for political reasons, it’s not for us, and I also want to ‘bite’ them about the license for the same Linux, Roundcube, etc. What made them think that by ‘chopping’ the interface in Python and taking away superuser rights they can sell a finished product composed of developed and refined modules from the internet community distributed under GPL&etc.
I understand that negative responses will come my way demanding detailed justification of my subjective feelings, but I want to say that this network node also acts as a traffic balancer for 4 external channels to the Internet, each with its own characteristics. Another cornerstone was the need for one of several network interfaces to work in different address spaces, and I am ready to admit that applying VLANs everywhere they are needed and not needed is something I am not ready. The devices in use are like TP-Link TL-R480T+ — they don’t behave perfectly, having their quirks. This part was reasonably configured on Linux thanks to the official Ubuntu website. Each of these channels can "go down" at any moment, just as they can come back up. If you're interested in the script that's currently working (which deserves a separate publication) — please write in the comments.
The solution under consideration does not claim to be unique, but it raises the question: "Why adapt to dubious third-party products with serious hardware requirements when we can consider an alternative?"
While there's a list from Roskomnadzor in Russia, in Ukraine, there is an attachment to the National Security Council's Resolution (e.g. ), local leaders are also vigilant. For instance, we were given a list of banned sites, which management believes worsen productivity in the workplace.
Engaging with colleagues at other enterprises where all sites are banned by default and access to specific sites can only be granted upon request from a supervisor, we respectfully smiled, reflected, and "pondered the problem," coming to the realization that life is still good, leading us to begin our search.
Having the ability not only to analytically view what is written in "housewives' books" about traffic filtering but also to observe what's happening on the channels of different providers, we noted the following recipes (any screenshots are slightly cropped, please understand the request):
Provider 1
— doesn't stress and imposes its own DNS servers and transparent proxy servers. Well, what can we say? .. at least we have access where we need it (if we need it :))
Provider 2
— believes that their upstream provider should take care of this; tech support from the upstream provider even admitted why I couldn't open the necessary non-banned site. I think this image will amuse you 🙂
As it turns out, they translate the names of banned sites into IP addresses and block specifically those IPs (they're not concerned that there might be 20 sites hosted on this IP).
Provider 3
— allows traffic through to the destination but does not permit it to come back on the route.
Provider 4
— prohibits all packet manipulations in the specified direction.
What to do with VPNs (respect for the Opera browser) and browser plugins? Initially experimenting with the Mikrotik nodes, we even came up with a resource-intensive L7 recipe that we later had to abandon (there can be quite a few prohibited names, it’s sad when, apart from our direct routing duties, the processor load on the PPC460GT reaches 100% due to 30 expressions).
.
What became clear:
DNS on 127.0.0.1 is definitely not a panacea; modern browser versions do allow bypassing such troubles. It’s not possible to limit all users with reduced rights, and one must not forget about the large number of alternative DNS. The internet is not static, and besides new DNS addresses, prohibited sites purchase new addresses, change top-level domains, and can add/delete a character in their address. However, something like this still has the right to exist:
ip route add blackhole 1.2.3.4It would be quite effective to obtain a list of IP addresses from the list of prohibited sites, but due to the reasons mentioned above, we turned our considerations to Iptables. There was already a functioning load balancer on CentOS Linux release 7.5.1804.
The user's internet must be fast, and the browser should not wait half a minute concluding that the page is not available. After long searches, we arrived at this model:
File 1 -> /script/denied_host, list of prohibited names:
test.test
blablabla.bubu
torrent
pornoFile 2 -> /script/denied_range, list of prohibited address spaces and addresses:
192.168.111.0/24
241.242.0.0/16Script file 3 -> ipt.sh, performing work with ipables:
# считываем полезную информацию из перечней файлов
HOSTS=`cat /script/denied_host | grep -v '^#'`
RANGE=`cat /script/denied_range | grep -v '^#'`
echo "Stopping firewall and allowing everyone..."
# сбрасываем все настройки iptables, разрешая то что не запрещено
sudo iptables -F
sudo iptables -X
sudo iptables -t nat -F
sudo iptables -t nat -X
sudo iptables -t mangle -F
sudo iptables -t mangle -X
sudo iptables -P INPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -P OUTPUT ACCEPT
#решаем обновить информацию о маршрутах (особенность нашей архитектуры)
sudo sh rout.sh
# циклически обрабатывая каждую строку файла применяем правило блокировки строки
for i in $HOSTS; do
sudo iptables -I FORWARD -m string --string $i --algo bm --from 1 --to 600 -p tcp -j REJECT --reject-with tcp-reset;
sudo iptables -I FORWARD -m string --string $i --algo bm --from 1 --to 600 -p udp -j DROP;
done
# циклически обрабатывая каждую строку файла применяем правило блокировки адреса
for i in $RANGE; do
sudo iptables -I FORWARD -p UDP -d $i -j DROP;
sudo iptables -I FORWARD -p TCP -d $i -j REJECT --reject-with tcp-reset;
done
The use of sudo is due to the fact that we have a small hack for control through the WEB interface, but as experience using this model for more than a year has shown, the WEB is not so necessary. After implementation, there was a desire to introduce the list of sites into a database, etc. The number of blocked hosts is over 250 + a dozen address spaces. There is indeed a problem when transitioning to a site via an https connection, as I, system administrator, have complaints against browsers :), but these are isolated cases; most of the responses to lack of access to the resource are still on our side, and we also successfully block Opera VPN, plugins like friGate, and telemetry from Microsoft.
Source: habr.com
