Fedoras Napisano Maj 20, 2023 Zgłoszenie Share Napisano Maj 20, 2023 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. Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
tomcio Napisano Maj 20, 2023 Zgłoszenie Share Napisano Maj 20, 2023 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 https://github.com/firewalld/firewalld/blame/2b58cb7d4a973ddb34d9084de542c433e68aec50/src/firewall-cmd.in#L432 Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
Fedoras Napisano Maj 27, 2023 Autor Zgłoszenie Share Napisano Maj 27, 2023 Tak, znam ten sposóbhttps://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źć. Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
tomcio Napisano Maj 27, 2023 Zgłoszenie Share Napisano Maj 27, 2023 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 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 Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
Fedoras Napisano Czerwiec 3, 2023 Autor Zgłoszenie Share Napisano Czerwiec 3, 2023 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ć? Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
tomcio Napisano Czerwiec 3, 2023 Zgłoszenie Share Napisano Czerwiec 3, 2023 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 Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
Fedoras Napisano Czerwiec 10, 2023 Autor Zgłoszenie Share Napisano Czerwiec 10, 2023 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. Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
SeeM Napisano Czerwiec 10, 2023 Zgłoszenie Share Napisano Czerwiec 10, 2023 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. Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
Fedoras Napisano Czerwiec 17, 2023 Autor Zgłoszenie Share Napisano Czerwiec 17, 2023 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. Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
SeeM Napisano Czerwiec 18, 2023 Zgłoszenie Share Napisano Czerwiec 18, 2023 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. Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
Fedoras Napisano Lipiec 1, 2023 Autor Zgłoszenie Share Napisano Lipiec 1, 2023 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? Odnośnik do komentarza Udostępnij na innych stronach More sharing options...
Rekomendowane odpowiedzi
Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto
Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.
Zarejestruj nowe konto
Załóż nowe konto. To bardzo proste!
Zarejestruj sięZaloguj się
Posiadasz już konto? Zaloguj się poniżej.
Zaloguj się