Jump to content

Firewalld - blokowanie całego ruchu wychodzącego poza wybranymi portami


Fedoras
 Share

Recommended Posts

W 2013 roku nie było możliwości blokowania całego ruchu wychodzącego poza wybranymi portami:
https://lists.fedorahosted.org/pipermail/firewalld-users/2013-February/000053.html
Czy
coś się zmieniło?
Ostatnio walczyłem z Rocky Linux i w końcu musiałem wrócić do iptables, bo w firewalld nie znalazłem takich możliwości.

Link to comment
Share on other sites

Da się

https://fedoraproject.org/wiki/Firewalld?rd=FirewallD#Direct_options

Przykład z dozwolonym tylko portem 80 zajumany stąd https://serverfault.com/questions/618164/block-outgoing-connections-on-rhel7-centos7-with-firewalld

firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -p tcp -m tcp --dport=80 -j ACCEPT
firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 1 -j DROP

Btw spojrzałem w git blame i wygląda na to, że tę opcję dodano jakieś 10 lat temu, mniej więcej pół roku po zalinkowanej przez ciebie wypowiedzi :D 

https://github.com/firewalld/firewalld/blame/2b58cb7d4a973ddb34d9084de542c433e68aec50/src/firewall-cmd.in#L432

Link to comment
Share on other sites

Tak, znam ten sposób
https://superuser.com/questions/1391650/how-can-i-configure-firewalld-to-block-all-outgoing-traffic-except-for-specific
ale to załatwia tylko ipv4. Potem drop dla ipv6?, icmp w obydwu wersjach?, a co z IGMP czy innymi?

Chodziło mi raczej o odpowiednik polityki DROP OUTBOUND, tak żeby jedną regułą/polityką zablokować wszystko, co chciałoby nawiązywać połączenia na zewnątrz, a nie blokować pojedyncze dziurki w sitku. Nic takiego nie mogę znaleźć.

Link to comment
Share on other sites

Czyli tobie bardziej chodzi o permanentny panic mode. Fakt nie ma prostego przełącznika (nie licząc tego --panic-on, który działa tylko do restartu) trzeba wszystkie protokoły podać osobno. No ale od czego jest bash jak nie od ułatwiania sobie życia :D  Na szybko skleciłem takie coś i wydaje się działać :)

#!/bin/bash

cat /etc/protocols | awk '{print $1}' | sed '/^#/d' | while read line; do
	firewall-cmd --add-rich-rule="rule protocol value=$line drop"
done

 

Link to comment
Share on other sites

Tak. Chodzi mi o panic mode, ale nie docelowo tylko jako bazę, podstawę, politykę, a następnie możliwość dodawania pozwolenia na konkretne protokoły i porty. Tak, żeby dostępne były tylko te połączenia, które jawnie zdefiniuję w regułach i nic innego. Do firewalld miał być zbudowany jakiś język. Może w nim da się coś takiego wyrzeźbić?

Link to comment
Share on other sites

5 godzin temu, Fedoras napisał:

Do firewalld miał być zbudowany jakiś język. Może w nim da się coś takiego wyrzeźbić?

Tak, Rich Language, skorzystałem z niego w tym skrypcie. Niestety nie da się w nim zablokować wszystkiego, trzeba określić protokół, serwis albo inny element. Ten język nie został wymyślony po to aby blokować wszystko z marszu, a po to aby jeszcze bardziej szczegółowo określić co ma być zablokowane lub odblokowane.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/configuring_complex_firewall_rules_with_the_rich-language_syntax

Link to comment
Share on other sites

OK. Jeszcze inaczej. Dawno, dawno temu uczono mnie, że w firewallingu istnieją dwie podstawowe polityki
- pozwól na wszystkie protokoły/ porty i blokuj te niepożądane
- blokuj wszystkie protokoły/porty i pozwól na te pożądane
Pamiętam długie dyskusje, która z tych polityk jest "lepsza". Firewalld realizuje pierwszą z tych polityk. Moje pytanie dotyczyło możliwości zastosowania drugiej z nich w równie prosty sposób jak pierwszej.

Link to comment
Share on other sites

3 godziny temu, Fedoras napisał:

- blokuj wszystkie protokoły/porty i pozwól na te pożądane

W przypadku ruchu przychodzącego jest to dosyć łatwe. W dokumentacji poszczególnych produktów jest napisane, jakie porty należy otworzyć. Dla ruchu wychodzącego jest dużo trudniej, ponieważ mało kto nawet wie, do czego jego produkt się łączy w celu aktualizacji, czy aktywacji. Zwykle do bardzo rozbudowanego CDN w rodzaju Cloudflare, albo Akamai, którego producent oprogramowania sobie wykupił oraz repozytoriów Dockera, PyPI, NPM, czy Mavena. Taki Red Hat to nawet opisuje - https://access.redhat.com/solutions/65300 - ale zwykle jest zakładane, że oprogramowanie ma nieograniczony dostęp do całego internetu.

Link to comment
Share on other sites

W dniu 10.06.2023 o 09:52, SeeM napisał:

oprogramowanie ma nieograniczony dostęp do całego internetu.

No i właśnie to mnie boli. Chciałbym poznawać co, gdzie i dlaczego się łączy z mojego prywatnego komputera.

Nie chciałbym, żeby "coś" z mojego komputera łączyło się ze stronami pedofilskimi czy dokonywało włamań lub DDOSów. Czy ktoś może dać głowę, że jego OS jest "czysty" i nie podłapał żadnych świństw? Bez kontroli nad tym jesteśmy ugotowani.

Link to comment
Share on other sites

W dniu 17.06.2023 o 05:31, Fedoras napisał:

No i właśnie to mnie boli. Chciałbym poznawać co, gdzie i dlaczego się łączy z mojego prywatnego komputera.

Nie chciałbym, żeby "coś" z mojego komputera łączyło się ze stronami pedofilskimi czy dokonywało włamań lub DDOSów. Czy ktoś może dać głowę, że jego OS jest "czysty" i nie podłapał żadnych świństw? Bez kontroli nad tym jesteśmy ugotowani.

Są do tego narzędzia. Na linusowym pulpcie możesz zainstalować Wireshark. Włącz przechwytywanie pakietów i zostaw komputer włączony na kilka dni, w czasie których możesz go normalnie używać. Przeglądanie tego ruchu to jestpraca, ale to w końcu cały ruch sieciowy ze stacji roboczej. Będzie tego dużo.

Jeżeli chcesz wiedzieć, co wychodzi z Twojej sieci, a nie tylko jednego komputera, potrzebujesz mieć zainstalowany tcpdump na routerze. Niektóre modele mają go fabrycznie, ale jeżeli będą zainfekowane, to podejrzany ruch można przez takim tcpdumpem ukryć. Najlepiej mieć do tego router-komputer z OpnSense/PfSense i dwoma interfejsami sieciowymi, albo chociaż OpenWRT. Jeżeli masz jakiś stary komputer i dowolną gigabitową kartę sieciową, możesz (powiedzmy na dwa tygodnie) postawić sobie na nim jakieś *Sense i niech pozbiera dane. To również jest dużo pracy i równie dużo ich analizy.

Ale będą też dobre strony: po takie analizie nie będziesz już miał wątpliwości, do czego potrzebujesz domowego serwera DNS. Może to być gotowiec w rodzaju pihole na jakimś starym raspberry, lub ręcznie wyrzeźbiony Bind, który będzie blokował strony z publicznych list typu https://github.com/MajkiIT/polish-ads-filter/blob/master/STATEMENT.md  , zawierających niedawno wygasłe domeny, zainfekowane oraz z jakiegoś powodu podejrzane strony.

Link to comment
Share on other sites

  • 2 weeks later...

Do wiresharka i tcpdumpa trzeba mieć dużo samozaparcia, jeszcze więcej czasu, a przede wszystkim podejrzenie graniczące z pewnością, że coś jest nie tak.Dużo ruchu wychodzącego można regulować na proxy, a najprostsze routery z firewallem pozwalają na zastosowanie polityki DENY from ANY to ANY, a następnie dopuszczanie pożądanych protokołów/portów
Mnie zastanawia dlaczego nie umożliwiono zastosowania takiej polityki w firewalld. Na pewno nie jest to niedopatrzenie. Może wyszły jakieś dokumenty RFC o których nie wiem, albo przyjęto jakieś standardy dotyczące stacji roboczych, że powinny puszczać cały ruch na zewnątrz, poza tym który jawnie ograniczy administrator?

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...