[F18] Firewalld - Jak Zmienić Domyślną Regułę Łańcucha?

[@WalDo]

W F18 domyślnym firewallem ma być firewalld. Zacząłem się trochę bliżej temu przyglądać i jakoś nie mogę znaleźć najprostszej rzeczy tj. możliwości zmiany domyślnego zachowania łańcucha. Nie podoba mi się przede wszystkim INPUT i FORWARD domyślnie ustawione na ACCEPT. Chciałbym zmienić na słuszniejsze wg mnie DROP.

Niby jest jakiś graficzny interfejs, ale przypomina bardziej firestartera albo podobna aplikację i umożliwia dodawanie/usuwanie/modyfikację reguł poza domyślną obsługa łańcucha. W firewall-cmd też nie znajduję takiej opcji.

 

Przeglądam stronę https://fedoraproject.org/wiki/FirewallD, ale nie potrafię odszukać jakieś rozsądnej dokumentacji (lub odnośników do niej) dotyczącej sposobu konfiguracji. Archiwum list mailingowych też wygląda nader ubogo.

Google po wpisaniu "firewalld" zgodnie ze swoją zasadą "każdy użytkownik jest debilem i/lub cierpi na dysgrafię" poprawia mnie i wyświetla wyniki o "firewall" i iptables

 

[EDIT]

Rozpisałem się o bzdetach i nie wiem czy nie rozmyłem w tym pytania podstawowego:

 

Jak w firewalld wydać polecenie równoważne poleceniu "iptables -P INPUT DROP" i jak zapisać to w konfiguracji (w ktorych plikach?).

 

Oczywiście zachęcam również do bardziej ogólnej dyskusji o firewalld, bo chyba pomału trzeba się zacząć żegnać ze starym, poczciwym iptables.

[Mentat]

Z tego co widze bedzie wybór i iptables nadal bedzie dostepne. Ogólnie to nie rozumiem kto firewalld wlasciwie tworzy, gdzie jest jakas konkretne dokumentacja i na ile to jest stabilne. Troche mnie zaskakuje zmiana tak waznego elementu jak zapora na cos malo znanego i nieprzetestowanego.

W ogóle w F18 ostro jada. Zmiana menedzera pakietów, zapory sieciowej, /tmp jako ramdysk (= znikanie zawartosci po restarcie). Oj bedzie sie dzialo.

[Fedoras]

Jak w firewalld wydac polecenie równowazne poleceniu "iptables -P INPUT DROP" i jak zapisac to w konfiguracji (w ktorych plikach?).

 

Moze cos takiego, umieszczone w /etc/firewalld/zones/mypublic.xml:

 

<?xml version="1.0" encoding="utf-8"?>

<zone name="mypublic" immutable="True" target="DROP">

<short>My public</short>

<description>My public zone. I do not trust the other computers on networks. Only incoming SSH connections are accepted.</description>

<service name="ssh"/>

</zone>

Immutable chyba mozna zmieniec na false.

 

Wyglada na to, ze w katalogu /usr/lib/firewalld/zones/ sa gole szablony z którymi dopiero trzeba cos zrobic. Niestety nie mam zainstalowanego firewalld i nie moge przetestowac.

 

Tutaj sposób na dodawanie uslug z uzyciem firewall-cmd

http://gomix.fedora-ve.org/projects/fedobetatest/wiki/Firewalld?version=14

 

At Mentat. Z tego co widze firewalld to kupa skryptów napisanych w jezyku wezowym, a tworza go rózni ludzie np. Thomas Woerner <[email protected]>, Jiri Popelka <[email protected]>, John Dennis <[email protected]>, Dan Walsh <[email protected]> Wszyscy z RedHata.

[@WalDo]

Wiem, ze mozna zostac przy iptables i na pewno z tego skorzystam Jednak chcialbym sprawdzic w jaki sposób przeniesc reguly iptables do firewalld i juz na podstawowym "iptables -P" sie zacinam.

 

Tutaj sposób na dodawanie uslug z uzyciem firewall-cmd

http://gomix.fedora-ve.org/projects/fedobetatest/wiki/Firewalld?version=14

Dodawanie uslug czy nawet ogolnie regul jest stosunkowo proste, jest firewall-config, w którym mozna sobie nawet to wyklikac a potem sprawdzic co i gdzie sie zapisalo. Tylko to troche przypomina reverse engineering a nigdzie nie moge znalezc jakies dokumentacji, zalozen itp.

Mnie chodzi o podstawowa regule lancucha. Pomalu sobie przypominam nazewnictwo, bo dawno przy firewallu nie dlubalem. Chodzi mi o ogólna polityke dla danego lancucha. Wg mnie z zasady INPUT powinien byc DROP a nie ACCEPT - nie mam zadnego serwera wystawianego na zewnatrz, nie chce, zeby ktokolwiek wchodzil na mój komputer - kazdy INPUT nie zainicjowany przeze mnie traktuje jako potencjalny atak. I tego w firewalld nie moge znalezc! Oczywiscie jest obejscie: wystarczy wydac polecenie w konsoli, ale to troche przypomina uruchamianie kijem od szczotki silnika w maluchu, kiedy sie linka od rozrusznika zerwala.

[Mentat]

At Mentat. Z tego co widze firewalld to kupa skryptów napisanych w jezyku wezowym, a tworza go rózni ludzie np. Thomas Woerner <[email protected]>, Jiri Popelka <[email protected]>, John Dennis <[email protected]>, Dan Walsh <[email protected]> Wszyscy z RedHata.

 

Hmm, to powiedzcie mi czy to jest tylko jakas nakladka na iptables czy wynajduja kolo od nowa (= takze nowe bledy)?

 

Tez ustawiam domyslna akcje na DROP. Nie lubie domyslnego ustawienia z odbijaniem jako "prohibited". Mniej regulek i wpisy latwiej dodawac (nie trzeba wstrzeliwac sie w srodek lancucha tylko wystarczy dodac regule na koncu).

[@WalDo]

Wyglada na nakladke na iptables, bo polecenie iptables dziala, ale reguly nie maja nic wspólnego z /etc/sysconfig/iptables. Niemniej poleceniem iptables mozna dodac nowa regule albo tak jak pisalem powyzej zmienic polityke dla lancucha.

 

Najwazniejszy ficzer tego firewalld to chyba mozliwosc ustawienia stref i (stosunkowo) latwego przelaczania sie miedzy nimi. Jest kilka stref predefiniowanych (np. public, external, internal, home, work) i mozna w kazdej z nich miec uruchamiane inne uslugi, inaczej odpowiadac na ICMP itd.

[Fedoras]

Drop.xml jako strefa chyba zalatwia caly INPUT nie inicjowany z wnetrza sieci. Ja zastanawiam sie jak w firewalld ustawic OUTPUT na DROP po to, by dopuscic nawiazywanie polaczen tylko do konkretnych uslug na zewnatrz. Nie widze tez FORWARDu.

Dawno temu wygenerowalem sobie zestaw regul przy pomocy Shorewalla, a potem juz pracowalem na wyniku iptables-save. Tam dobrze widac domyslne reguly dla INPUT, OUTPUT i FORWARD w tablicach.

Chyba o to chodzi w Firewalld.

 

Jeszcze firewalld z NetworkManager:

https://fedoraproject.org/wiki/QA:Testcase_firewalld_and_NetworkManager

i testy:

https://fedoraproject.org/wiki/Test_Day:2012-11-21_Network_Manager_and_FirewallD?rd=Test_Day:2012-10-25_Network_Manager_and_FirewallD

 

A walka o dokumentacje jest zacieta i opiera sie o Bugzille:

https://bugzilla.redhat.com/show_bug.cgi?id=806511

 

Tak mysle, ze trzeba to odlozyc do F19

[@WalDo]

U mnie zmiana strefy na drop i restart uslugi nie wprowadzily zmiany polityki. Wciaz mam Chain INPUT (policy ACCEPT)

[Fedoras]

Wciaz mam Chain INPUT (policy ACCEPT)

 

No to lipa.

 

Wedlug mnie zarówno iptables jak i firewalld sa nakladkami na jadro. Iptables trzymal wszystkie reguly w jednym pliku konfiguracyjnym, a firewalld trzyma je w wielu plikach .xml. Nowoscia jest integracja firewalld z dbusem i wplatanie w caly system tak, zeby uzytkownik znanego systemu komercyjnego mógl sobie wyklikac ochrone komputera nie majac pojecia o co w tym chodzi. Byc moze instrukcja obslugi do firewalld jest przygotowywana w Redmond.

 

W zasadzie nie mam nic przeciwko temu, aby obsluga programu byla latwa i wykonywana przez interfejs graficzny, ale nie kosztem bardziej precyzyjnej regulacji bez udzialu myszy. A zanosi sie, ze tak bedzie.

Iptables nie poddawal sie nakladkom graficznym i byl klopotliwy mimo ich stosowania, zatem musi polec zgodnie z zasada, ze masowosc produktu pociaga za soba jego pogorszenie i wykonanie z gorszych (tanszych) elementów.

 

Definiowanie róznych stref, z róznymi uslugami, za pomoca iptables zawsze bylo mozliwe, a skrypty shorewalla umozliwialy to bardzo dobrze.

 

[@WalDo]

W zasadzie nie mam nic przeciwko temu, aby obsluga programu byla latwa i wykonywana przez interfejs graficzny, ale nie kosztem bardziej precyzyjnej regulacji bez udzialu myszy. A zanosi sie, ze tak bedzie.

Byc moze zostanie to jakos dopracowane, ale póki co Fedora wchodzi z kolejnym produktem w wersji alfa do wydania stabilnego. No, ale dopóki mozna bedzie zmienic na iptables, to nie bede narzekal.

Szkoda, ze uparli sie wrzucic pare bzdetów typu ownCloud do wydania i przesuwaja termin w niskonczonosc. Juz 5 tygodniu obsuwy w stosunku do pierwotnego planu a do 11 grudnia to jeszcze im moze z tydzien lub dwa dojsc a na koniec i tak beda latac jakis produkt.

 

 

To co z ta domyslna polityka? ma ktos pomysl?

[Fedoras]

Zainstalowalem i póki co poddaje sie. Wyglada to zupelnie inaczej niz w teorii. Przy okazji wersja 0.2.5 w F17 jeszcze nie obsluguje immutable="true"

https://lists.fedorahosted.org/pipermail/firewalld-users/2012-July/000023.html

ani nie ma zadnego firewall-config

https://bugzilla.redhat.com/show_bug.cgi?id=814882#c3

 

Chyba jest to surówka i póki co domyslne polityki moga byc niezmienialne. Potrzebuja testerów i dlatego dolaczaja do F18

 

[@WalDo]

Ja trenuje na alfa F18, czyli na wersji w której firewalld jest domyslnym firewallem. firewall-config jest i dziala, ale bez mozliwosci ustawienia polityki domyslnej dla lancucha. Interfejs siermiezny jak firewall w routerze za 20 pln. Funkcje podstawowe, ale widac, ze jednak cos idzie do przodu w porównaniu z F17. Zobaczymy. Na razie zdecydowanie

systemctl disable firewalld.service
systemctl enable iptables.service

[Raven]

Szkoda, ze uparli sie wrzucic pare bzdetów typu ownCloud do wydania i przesuwaja termin w niskonczonosc. Juz 5 tygodniu obsuwy w stosunku do pierwotnego planu a do 11 grudnia to jeszcze im moze z tydzien lub dwa dojsc a na koniec i tak beda latac jakis produkt.

Bzdety typu ownCloud nie sa przyczyna opóznien, tylko przepisana anaconda i nastepca preupgrade o nazwie fedup, z którymi sa problemy.

[@WalDo]

 

Bzdety typu ownCloud nie sa przyczyna opóznien,

Tak rzucilem bez wiekszego zastanowienia. Domyslam sie, ze akurat chmura nie jest krytyczna dla wydania i mozna nad nia pracowac w fazie beta. Slabo, ze zabrali sie za zmiany w anakondzie - moim zdaniem na gorsze, szczególnie jesli chodzi o reczny podzial dysku. Instalator Fedory nigdy jakis mocno przyjazny nie byl, ale jak instalowalem F18 alfa obok "zywej" F17 to mocno mi reka drzala przy wyborze miejsca, zeby F17 i partycji wspólnych (z danymi) nie wyslac w kosmos.

 

Do tego Secure Boot w kolumnie "% Complete" od dlugiego czasu ma 99% Mam nadzieje, ze "stoperami" nie sa obsluga LLVM czy usermode migration, bo jesli tabelka na stronie projektu jest aktualna, to wykonanie 20% nie napawa optymizmem.

[Raven]

Mam nadzieje, ze "stoperami" nie sa obsluga LLVM czy usermode migration, bo jesli tabelka na stronie projektu jest aktualna, to wykonanie 20% nie napawa optymizmem.

Nie sa. Architektura Power jest "drugorzedna" (Secondary Architecture), wiec obsluga przez nia LLVM nie moze byc blockerem, a migracja z Usermode na polkit zostala przesunieta na F19.