Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
[quote=uzytkownikubunt]Trzeba po ścieżkach do plików wykonywalnych (czego chyba dla wyjścia czyste iptables nie umie, trzeba chyba kombinować z systemami ACL) albo po kontach użytkowników i na tych kontach uruchamiać aplikacje mające dostęp do netu, albo po przestrzeniach nazw sieciowych (network namespace) albo jeszcze innych.[/quote]
Ja czekam, aż w końcu zaimplementują obsługę sieci w AppArmor. Wtedy będzie można konkretnym procesom zezwalać na połączenia na konkretne adresy/porty.
Teoretycznie to w oparciu o cgroups można by zrobić mechanizm ogarniający wszystkie połączenia wychodzące. Nigdy tego nie robiłem ale pewnie coś by dało radę wymyśleć. Standardowo wszystkie pakiety mają mark=0x0. Te pakiety można blokować na zaporze dodając dopasowanie w oparciu o tego marka. W cgroups dla odpowiednich aplikacji ustawić mark=0x1 i ten mark przepuścić na zaporze. Wtedy wszystkie procesy w systemie będą mieć mark=0x0, a np. firefox mark=0x1 i tylko ten proces będzie w stanie wysłać pakiety w świat. Oczywiście trzeba by cały system uwzględnić (odpowiednie usługi) w cgroups i trochę z tym by roboty było. Może sobie kiedyś rzucę okiem na to. Choć pewnie wcześniej ci z systemd opracują firewall procesowy i nie będzie trzeba aż tak kombinować. xD
Ten moduł -m owner się nie nadaje zbytnio. Cały syf, który ci się wgra, będzie miał albo ID=0 albo ID=1000, czyli root albo twój użytkownik. Wiec nie będzie miał problemów z komunikacją. Ten moduł moim zdaniem nie powstał w celu utrudnienia komunikacji wirusom i innym takim. Ja przy jego pomocy oznaczam sobie pakiety wychodzące, choć jest też parę innych zastosowań, np. kontrola rodzicielska innych użytkowników w systemie, zwłaszcza w połączeniu z modułem -m time. xD
Offline
Teoretycznie to w oparciu o cgroups można by zrobić mechanizm ogarniający wszystkie połączenia wychodzące.[/quote]
Rozwiazanie jest we wczesniejszych wpisach "Jacekalex" cgroups i przelozenie na blokujace lub wypuszczajace regolki iptables.
Mozna to zrobic z klassyfikatorem net_cls. W wersji bardziej zlozonej mozna wykorzystac dodatkowo kolejke dyscyplinowania HTB ktora odbierze zablokowanym pakietom z okreslonym markiem mozliwosc opuszczenia kompa.
Na ten sam temat, ale troche z innej beczki, szukam czegos do wizualizacji dzialania regol a co za tym idzie wizualizacji ruchu pakietow na okreslonej konfiguracji regol, czegos podobnego do "gressgraph'a" z tej strony:
http://www.ceus-now.com/debugging-iptables-using-live-packet-views/
lub
http://www.vitavonni.de/blog/200704/2007040901-visualizing-iptables.html
To nie jest wizualizacja logow tylko wizualizacja przeplywu pakietow, uwazam, ze pogladowo to rewelka tylko miec takie cos na Jessie to inna sprawa.
Moze ktos wie jak to zrobic na Jessie?Ostatnio edytowany przez Novi-cjusz (2016-06-11 21:09:00)
------------------------------------------------------------------------------------
"Inveniam viam aut faciam" : I will either find a way, or I shall make one
"Złoto to pieniądz królów, srebro to pieniądz dżentelmenów, barter to pieniądz chłopów ale dług to pieniądz niewolników."
Offline
Ja mówiłem o nieco innym mechanizmie opartym o cgroups. Nigdy go nie robiłem i nie wiem dokładnie jakby to wyglądało w praktyce. To był tylko zapis teoretyczny.
W wersji bardziej zlozonej mozna wykorzystac dodatkowo kolejke dyscyplinowania HTB ktora odbierze zablokowanym pakietom z okreslonym markiem mozliwosc opuszczenia kompa.[/quote]
To w ogóle nie ma związku z blokowaniem pakietów w iptables, bo iptables sam potrafi to robić.
A co do przepływu pakietów, to ja tam zawsze sobie pomagam tym obrazkiem: http://imgur.com/MrSZogoOstatnio edytowany przez morfik (2016-06-12 12:52:36)
Offline
Ten http://imgur.com/MrSZogo obrazek to klasyka i ma przynajmniej 100 innych wersji, ale ta jest chyba najlepsza, to ogolna informacja i nie odnosi sie do roznych indywidualnych skryptow iptables. Wlasnie w tych roznych i odmiennych implementacjach znakomita wizualizacja rzeczywistego przeplywu pakietow na konkretnej konfiguracji firewalla bylyby podane http://www.ceus-now.com/debugging-iptables-using-live-packet-views/ lub http://www.vitavonni.de/blog/200704/2007040901-visu … iptables.html narzedzia (tylko bardziej wspolczesne)Gdzie cos takiego mozna znalezc???
Zawsze zastanawialy mnie 2 sprawy:
- dlaczego polityka domyslna (np 3x DROP) umieszczana jest na poczatku skryptu, skoro nawet zgodnie z powyzszym obrazkiem jako ostatnia powinna byc umieszczana na koncu kazdego lancucha, a nikt tak nie robi.
- dlaczego niektorzy tworza skrypty iptables zgodne z fizycznym przeplywem pakietow tzn: INPUT - FORWARD - OUTPUT. Natomiast inni tworza zgodne z kolejnoscia tablic tzn: FILTER - NAT - MANGLE - RAW?
Ostatnio edytowany przez Novi-cjusz (2016-06-12 14:53:49)
Offline
Zasada zawsze jest taka sama, pakiety przechodzą kolejne reguły w łańcuchu. A jakie łańcuchu, to masz na tym obrazku. W efekcie powinieneś być w stanie zwirtualizować sobie w głowie przepływ pakietów przez filtr bez większego problemu. Zawsze masz -j TRACE, który ci w tym może pomóc.
- dlaczego polityka domyslna (np 3x DROP) umieszczana jest na poczatku skryptu, skoro nawet zgodnie z powyzszym obrazkiem jako ostatnia powinna byc umieszczana na koncu kazdego lancucha, a nikt tak nie robi.
- dlaczego niektorzy tworza skrypty iptables zgodne z fizycznym przeplywem pakietow tzn: INPUT - FORWARD - OUTPUT. Natomiast inni tworza zgodne z kolejnoscia tablic tzn: FILTER - NAT - MANGLE - RAW?[/quote]
To już zależy od konkretnego człowieka. Kolejność aplikowanych reguł ma znaczenie, tj. jeśli dasz regułę "-P INPUT DROP" na końcu skryptu, to iptables w czasie nakładania reguł ze skryptu będzie otwarty przez parę milisekund na ruch sieciowy. Ja mam zawsze na samym początku reguły blokujące ruch na łańcuchach. Poniżej jest nagłówek moich skryptów:Kod:
#!/bin/sh ipt="$(which iptables) -t filter" $ipt -P INPUT DROP $ipt -P FORWARD DROP $ipt -P OUTPUT ACCEPT $ipt -F $ipt -X conntrack -FI dopiero po tym tworzę swoje łańcuchy i aplikuję reguły.
Offline
jeśli dasz regułę "-P INPUT DROP" na końcu skryptu, to iptables w czasie nakładania reguł ze skryptu będzie otwarty przez parę milisekund na ruch sieciowy[/quote]
Te slowa mi bardzo wiele tlumacza, czyli jak 3 x DROP jest na poczatku to ruch jest od poczatku zamkniety i dopiero w miare potrzeb go otwieramy. O to chodzilo.
Mnie najbardziej interesuje 3 x DROP na poczatku, i efektywne filtrowanie ruchu wyjsciowego na lancuchu OUTPUT (egress filtering).
Konfig gdzie z kompa moga wychodzic:
- loopback
- zapytania DNS
- przegladarka
------------------------------------------------------------------------------------
"Inveniam viam aut faciam" : I will either find a way, or I shall make one
"Złoto to pieniądz królów, srebro to pieniądz dżentelmenów, barter to pieniądz chłopów ale dług to pieniądz niewolników."
Offline
Cały czas błądzisz.
Konfig gdzie z kompa moga wychodzic:
- loopback
- zapytania DNS
- przegladarka[/quote]
iptables nie służy do zarządzania praw z jakimi działają dane programy — dotyczy to również sieci.
Do tego służą zupełnie inne narzędzia.
Offline
Ja pisze o egress filtering a ty o czym?
Offline
[quote=Novi-cjusz]Ja pisze o egress filtering a ty o czym?[/quote]
iptables np nie wie czy połączenie nawiązuje przeglądarka, czy jakiś inny podejrzany program/proces.
Twoje założenia, że przykładowo mogą wychodzić połączenia tylko z przeglądarki są w praktyce bezsensowne.
Offline
No w połączeniu z oznaczaniem pakietów w cgroups, można nauczyć iptables rozpoznawać aplikacje ale to jest cholernie dużo roboty z oznaczeniem wszystkich niezbędnych systemowi usługi. Wtedy można by zablokować cały ruch w oparciu o marki i nadać procesowi firefox mark, który będzie przepuszczany na iptables i tak oznaczyć wszystkie pożądane aplikacje. Reszta będzie blokowana. Z tym, że ja jednak wolę już czekać na firewall procesowy od systemd. xD
Offline
iptables np nie wie czy połączenie nawiązuje przeglądarka, czy jakiś inny podejrzany program/proces.[/quote]
To wiemy, ale mozna sobie latwo poradzic blokujac wszystko a wypuszczajac ruch przegladarki, zapytan DNS i looback.
A sa jeszcze min 2 inne sposoby tylko o nich wiedza ci ktorzy czytali posty uwaznie.
Wszystko inne polegnie na domyslnym DROP
Wiec pomyliles sie uzywajac slow:Twoje założenia, że przykładowo mogą wychodzić połączenia tylko z przeglądarki są w praktyce bezsensowne.[/quote]
Jezeli juz to moze dalo by sie bardziej konstruktywnie.
------------------------------------------------------------------------------------
"Inveniam viam aut faciam" : I will either find a way, or I shall make one
"Złoto to pieniądz królów, srebro to pieniądz dżentelmenów, barter to pieniądz chłopów ale dług to pieniądz niewolników."Offline
[quote=morfik]No w połączeniu z oznaczaniem pakietów w cgroups, można nauczyć iptables rozpoznawać aplikacje ale to jest cholernie dużo roboty z oznaczeniem wszystkich niezbędnych systemowi usługi. Wtedy można by zablokować cały ruch w oparciu o marki i nadać procesowi firefox mark, który będzie przepuszczany na iptables i tak oznaczyć wszystkie pożądane aplikacje. Reszta będzie blokowana. Z tym, że ja jednak wolę już czekać na firewall procesowy od systemd. xD[/quote]
To się robi przy użyciu narzędzi do zarządzania kontrolą dostępu (wszelkiej maści SELinuksy, AppArmory itp) albo przy wykorzystaniu zaawansowanych kontenerów/piaskownic, które korzystają ze specjalnych narzędzi dostępnych bezpośrednio w jądrze (cgroups, namespaces, Seccomp i dziesiątki innych).
Dopiero w takim odizolowanym środowisku, z zupełnie niezależną od reszty systemu siecią, można się bawić w regułki iptables dotyczące danej aplikacji.
Offline
[quote=yossarian][quote=morfik]No w połączeniu z oznaczaniem pakietów w cgroups, można nauczyć iptables rozpoznawać aplikacje ale to jest cholernie dużo roboty z oznaczeniem wszystkich niezbędnych systemowi usługi. Wtedy można by zablokować cały ruch w oparciu o marki i nadać procesowi firefox mark, który będzie przepuszczany na iptables i tak oznaczyć wszystkie pożądane aplikacje. Reszta będzie blokowana. Z tym, że ja jednak wolę już czekać na firewall procesowy od systemd. xD[/quote]
To się robi przy użyciu narzędzi do zarządzania kontrolą dostępu (wszelkiej maści SELinuksy, AppArmory itp) albo przy wykorzystaniu zaawansowanych kontenerów/piaskownic, które korzystają ze specjalnych narzędzi dostępnych bezpośrednio w jądrze (cgroups, namespaces, Seccomp i dziesiątki innych).
Dopiero w takim odizolowanym środowisku, z zupełnie niezależną od reszty systemu siecią, można się bawić w regułki iptables dotyczące danej aplikacji.[/quote]
Selinux? Przyjemnej zabawy, chyba że weźmiesz RH lub CentOS.
Apparmor? podobno ma filtrować połączenia sieciowe, ale spróbuj zrobić globalną politykę Apparmora i trzymać w niej cały system.
Wykonalne, ale na pewno nie na poziomie Novicjusza, i jest z tym tyle certolenia, że 20 razy łatwiej można postawić jajo z Grsec i RBAC.
Filtrowanie sieciowe w AA też na razie jest podobno, modułu w kernelu do tego ani śladu.
Apparmor nie korzysta z seccomp, namespaces i cgroup, korzysta z własnego mechanizmu ACL, i nie kontroluje zasobów, tak jak cgroup.
Generalnie każdy system ACL musi korzystać z własnych mechanizmów, a nie połowy kernela, żeby zminimalizować ryzyko w przypadku błędu w mechanizmie seccomp, namespaces czy innego elementu, od którego zależy.
Kompromitacja SELINUxa czy Apparmora z powodu jakiegoś babola w innym module kernela oznacza śmierć danego systemu ACL.
Cgroup net_cls w połączeniu z netfilterem daje możliwość dosyć prostego i wygodnego wypuszczenia do netu tylko wybranych programów.
Pozdro
Offline
[quote=morfik]No w połączeniu z oznaczaniem pakietów w cgroups, można nauczyć iptables rozpoznawać aplikacje ale to jest cholernie dużo roboty z oznaczeniem wszystkich niezbędnych systemowi usługi. Wtedy można by zablokować cały ruch w oparciu o marki i nadać procesowi firefox mark, który będzie przepuszczany na iptables i tak oznaczyć wszystkie pożądane aplikacje. Reszta będzie blokowana. Z tym, że ja jednak wolę już czekać na firewall procesowy od systemd. xD[/quote]
Odbiegnę trochę od tematu. Na Androida jest fajna appka, zwie się [url=https://play.google.com/store/apps/details?id=app.greyshirts.firewall&hl=pl]NoRoot Firewall[/url]. Tworzy mostek VPN i blokuje np neta z FF. Nie wymaga root'a. Nie wiem jak oni to zrobili, ale jest fajne.
Offline
[quote=Jacekalex]Selinux? Przyjemnej zabawy, chyba że weźmiesz RH lub CentOS.
Apparmor? podobno ma filtrować połączenia sieciowe, ale spróbuj zrobić globalną politykę Apparmora i trzymać w niej cały system.
Wykonalne, ale na pewno nie na poziomie Novicjusza, i jest z tym tyle certolenia, że 20 razy łatwiej można postawić jajo z Grsec i RBAC.
Filtrowanie sieciowe w AA też na razie jest podobno, modułu w kernelu do tego ani śladu.
Apparmor nie korzysta z seccomp, namespaces i cgroup, korzysta z własnego mechanizmu ACL, i nie kontroluje zasobów, tak jak cgroup.[/quote]
Deweloperzy skupiają się głównie na mechanizmach do izolacji całych fragmentów systemu (mieszanka wirtualizacji/konteneryzacji i piaskownic) niż samego AppArmora/SELinuksa: obsługa cgroups, namespaces, brtfs, systemd, wayland, Flatpak, LXC, ubuntowe snappy itd. Wszystko to jest od razu rozwijane tak by zapewniać pełną izolację procesów od głównego systemu.
Można zobaczyć w jaki sposób zabezpieczany został Qubes OS. Nie ma tam kilometrowych regułek iptables, rzeźbienia w SELinux/AppArmor czy innych Grsec. Wszystko opiera się tam tylko na stosunkowo starej i topornej (bo pełnej wirtualizacji), ale bezpiecznej izolacji.
Generalnie każdy system ACL musi korzystać z własnych mechanizmów, a nie połowy kernela, żeby zminimalizować ryzyko w przypadku błędu w mechanizmie seccomp, namespaces czy innego elementu, od którego zależy.
Kompromitacja SELINUxa czy Apparmora z powodu jakiegoś babola w innym module kernela oznacza śmierć danego systemu ACL.[/quote]
Praktyka pokazuje co innego. Najbezpieczniejsze są standardowe i powszechnie stosowane mechanizmy.
Z autorskimi, nieoficjalnymi rzeczami bywają problemy.
Offline
Time (s) | Query |
---|---|
0.00012 | SET CHARSET latin2 |
0.00004 | SET NAMES latin2 |
0.00099 | SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='13.59.45.228' WHERE u.id=1 |
0.00067 | REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '13.59.45.228', 1731788551) |
0.00076 | SELECT * FROM punbb_online WHERE logged<1731788251 |
0.00084 | SELECT topic_id FROM punbb_posts WHERE id=302291 |
0.00178 | SELECT id FROM punbb_posts WHERE topic_id=28689 ORDER BY posted |
0.00083 | SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=28689 AND t.moved_to IS NULL |
0.00005 | SELECT search_for, replace_with FROM punbb_censoring |
0.00143 | SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=28689 ORDER BY p.id LIMIT 25,25 |
0.00085 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=28689 |
Total query time: 0.00836 s |