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/.
Strony: 1
Z reguły procesy wysyłają pakiety sieciowe bez większego skrępowania, bo w filtrze pakietów w OUTPUT jest zwykle "accept". Jeśli się tam ustawi "drop", to procesy będą mieć zabronioną komunikację ze światem. Każdy pakiet, który trafi na zaporę sieciową można zalogować np. dodają taką regułę:
add rule inet filter OUTPUT limit rate 30/minute burst 1 packets log flags all prefix "* OUTPUT * " counter drop
Co z kolei zwróci komunikat podobny do tego poniżej:
kernel: * OUTPUT * IN= OUT=bond0 SRC=192.168.0.135 DST=104.81.106.31 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=39568 DF PROTO=TCP SPT=56784 DPT=443 SEQ=3504435004 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B40402080A03AC71A60000000001030309) UID=1000 GID=1000[/quote]
Tam w tej regułce nftables został użyty "flags all", który czyni ten komunikat nieco bardziej nasycony informacją ale brakuje w nim numerka z PID'em procesu (ew. ścieżki do programu, który ten pakiet chciał wysłać). Jest co prawda UID i GUI, ale na ich podstawie nic zbytnio wywnioskować się nie da. xD
Jest jakiś sposób by ten PID uzyskać, tak by przy okazji poznać ścieżkę do programu, który próbuje się skomunikować ze światem? Netstat i inne tego typu narzędzia mogą być nieco pomocne ale co w przypadku, gdy proces się uruchomi, spróbuje wysłać pakiet i się zakończy?
Offline
Zablokować wszystko a otwierać per program via cgroup, to najprościej.
Jedyna wada - nie działa z KDE/Akregatorem, bo ten się przez socket unix czy gniazdo IPC komunikuje z kdeinit, kdeinit odpala kio - http.so , który to proces nie ma nic wspólnego z Akregatorem w drzewku procesów.
Takiej funkcjonalności jaką potrzebujesz nie ma w FW w ogóle, potrafią to systemy
ACL jak Apparmor czy SELinux. (AA teraz jest na zakręcie, w 4.19 działają łatki AA-network, od 4.20 AA podobnie jak SELinux będzie korzystał z SECMARK i tablicy SECURITY Netfiltera).
Jeszcze nie znam szczegółów, ale docelowo ma ten mechanizm AA-secmark brykać chyba w jaju 5.0.
W 4.20 są jakieś początki tego mechanizmu.
Rzuć okiem tutaj:
https://lists.ubuntu.com/archives/apparmor/2019-January/011906.html
https://lists.ubuntu.com/archives/apparmor/2019-January/011907.html
Jak AA-secmark będzie w standardowym jaju, to zrozumiesz,
po co się męczysz z profilami AA dla Systemd i jakimś kretyńskim full-system-policy. xD
Ostatnio edytowany przez Jacekalex (2019-02-06 10:46:09)
Offline
No ja chcę właśnie sobie taki fw na cgroups zrobić i sporo appek już jest w swoich grupach, choć docelowo to będzie mark 1 na allow, i mark 2 na block (albo coś podobnego). xD problem w tym, że mój system próbuje się komunikować ze światem i za bardzo nie wiem, które usługi próbują to robić. Np. miałem usługę od synchronizacji czasu. No to akurat wiedziałem, bo port był 123, a tych usług od synchronizacji czasu u mnie w systemie to jest aż jedna i dało radę ją wyłapać. xD Ale szereg procesów używa portu 443 albo 80 i jak ustalić na podstawie takiego komunikatu zapory, który to proces? Ewentualnie może jest inny sposób by to zrobić? Część rzeczy można przez netstat wyciągnąć ale jak proces się zakończy, to już go tam nie widać...
Offline
Jako, że w logu widnieje timestamp (co prawda, z dokładnością do 1s) to można spróbować skorelować pewne informacje. Są dwa ciekawe narzędzia lastcomm i forkstat . Generalnie to te narzędzia są w stanie zalogować wykonywane polecenia.
Dla przykładu, w logu jest komunikat:
Feb 06 11:57:02 morfikownia kernel: * IPTABLES:OUTPUT * IN= OUT=bond0 SRC=192.168.0.135 DST=206.252.253.41 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=35130 DF PROTO=TCP SPT=51620 DPT=443 SEQ=2106491040 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B40402080A7BFA98690000000001030309) UID=1000 GID=1000[/quote]
Szukając procesu w lastcomm ,Kod:
# lastcomm morfik --debug | grep 11:57:nic się nie zobaczy do momentu, aż proces się zakończy, czyli w sumie jeśli proces działa, to można go złapać zwykle przez netstat. Z kolei jeśli proces się zakończy to będzie widniał on w logu lastcomm z datą jego wywołania, czyli mniej więcej tą, która widnieje w logu nftables:
Kod:
CURRENT REC: wget |v3| 2.00| 0.00| 869.00| 1000| 1000| 22416.00| 0.00| 99233| 96424| X| 0|pts/11 |Wed Feb 6 11:57:02 2019Oczywiście tych procesów w danej sekundzie będzie zwykle więcej niż 1 i trzeba będzie się trochę wysilić by znaleźć ten, który chciał wysłać pakiet ale to powinno już pójść łatwo. xD
Z kolei jeśli chodzi o forkstat , to on monitoruje wywołania procesów w czasie rzeczywistym:Kod:
# forkstat -e exec -x -l | grep morfik 12:09:49 exec 102626 morfik pts/11 wget -c --no-check-certificate --referer=...Można by sobie to wyjście przekierować do pliku i tam później poszukać winowajcy. xD
Offline
A te appki, co się nie łączą, nie umieją zapłakać że ich do netu nie puszcza?
Poza Akregatorem wszystko, co miałem w systemie kiedykolwiek, zazwyczaj o net płakało osobiście, lub przynajmniej w logach pokazało, co je boli.
Dlatego Appka co nie ma neta, i nie wiadomo która, to mnie mocno dziwi.
Ostatnio edytowany przez Jacekalex (2019-02-06 12:16:18)
Offline
No z reguły płaczą ale też nie wszystkie. A poza tym, jak jakiś syf wlezie do systemu i będzie chciał wysłać coś na net, to będzie płakał, że "neta chce i dajta wyjść za FW"? xD
Offline
Na syf co wejdzie jest kilka metod, np Aide, Rkhuter, Tiger, IMA+EWM, itp.
Z reszta pomóż jakoś temu syfowi, do mnie jakoś nigdy żaden nie wszedł na razie.
Kilka razy sam chciałem taki syf jeden czy drugi zainstalować, i też nie dałem rady osobiście.
Dlatego filtrowanie OUTPUTU w FW trzeba skoordynować z ACL, żeby nie gadały z netem programy, które nie są chronione przez AA.
Do końca to zrobić trudno, ale np applet pogodowy dostał własne "gniazdko".
/usr/libexec/mate-applets/mateweather-applet (enforce)
Offline
No mi też nigdy żaden syf jeszcze nie wlazł ale lepiej być przygotowanym. xD Póki co to ustaliłem, że prawdopodobnie to jakieś kio_http mi nawiązuje te połączenia, pewnie przy odpalaniu amaroka albo jakiegoś komponentu, z którego on korzysta. Tak czy inaczej powiązane z kde.
Tu jest jeszcze parę rzeczy, które mi ludzie podrzucili:
https://www.linkedin.com/pulse/using-auditd-monitor-network-connections-alex-maestretti
https://serverfault.com/questions/352259/finding-short-lived-tcp-connections-owner-process/352275#352275
https://github.com/themighty1/lpfw
Offline
Auditd jest dopasowany do API Selinuxa.
Jak chciałem się dowiedzieć, co mi kasuje zawartość /run w systemie, to niestety auditd tego nie wyjaśnił mimo usilnych prób z mojej strony, aby to uczynił, dopiero RBAC Grsecurity wyjaśnił sprawę do końca.
Doceniłem wtedy ideę full-system-policy jak nigdy. xD
Co do Amaroka, to developerzy KDE chcieli zrobić wspaniale, wyszło jak zwykle.
Żeby uchwycić kio-http zainteresuj się poleceniem kioexec, u mnie siedzi w:
/usr/lib64/libexec/kf5/kioexec
to chyba przez niego kdeinit odpala połaczenia sieciowe.
Zawsze możesz popytać na oficjalnym forum KDE z resztą.
Albo pożegnać Amaroka, nie jest na szczęście monopolistą.
Offline
No mi auditd trochę rzeczy powiedział i udało się w końcu namierzyć winnego -- kdeinit4, no i to jest od amaroka, bo tylko on jeszcze nie został przepisany na kde5. Jak dałem marka na kdeinit4 i kdeinit5, to oznacza pakiety i można je złapać w nftables:
# nft list chain inet filter check-cgroup table inet filter { chain check-cgroup { ... meta cgroup { 513 } counter packets 21 bytes 1260 accept comment "kde" meta cgroup { 514 } counter packets 0 bytes 0 accept comment "kde-krusader" meta cgroup { 515 } counter packets 0 bytes 0 accept comment "kde-amarok" meta cgroup { 2048 } counter packets 0 bytes 0 accept comment "block apps" } }
Choć jak w amaroku pobieram napisy do piosenek, to jednak leci na mark od kdeinit a nie od amaroka. xD
# cat /sys/fs/cgroup/net_cls,net_prio/gui/user-apps/kde/amarok/net_cls.classid 515 # cat /sys/fs/cgroup/net_cls,net_prio/gui/user-apps/kde/net_cls.classid 513
Ciekawe czy się da to jakoś rozróżnić, bo jak to będzie wybór na zasadzie, że całe kde ma dostęp do netu lub go nie ma, to ciekawe środowisko zrobili. xD
Próbowałem złapać tego kioexec ale jakoś nie daje rady ani po ścieżce ani po nazwie, więc tylko kdeinit zostaje.
Offline
KDeinit też można łapać, ale to jest wyższa szkoła jazdy, dosyć losowa:
**************************************************************** ### Program: /usr/bin/kdeinit5 ### user: pacjent ### ................................................................ 15:debug:/ 14:rdma:/ 13:pids:/users/akregator 12:hugetlb:/ 11:net_prio:/ 10:perf_event:/ 9:net_cls:/users/akregator 8:freezer:/ 7:devices:/ 6:memory:/users/akregator 5:blkio:/users/akregator 4:cpuacct:/users/akregator 3:cpu:/users/akregator 2:cpuset:/ 1:name=openrc:/xdm 0::/xdm ................................................................ Apparmor: /usr/bin/akregator (enforce) ................................................................
Jak widać, o ile nie używam KDE, to kdeinit grzecznie siedzi w cgroup i profilu AA Akregatora.
Ale jak coś odpali kdeinit wcześniej, to już wisi jako demon i następne programu gadają z kdeinit przez dbusa.
Reasumując, trzeba przez AA i cgroup ogarnąć kdeinit bezpośrednio.
mam takie 3 dziadostwa:
/usr/bin/kdeinit5 /usr/bin/kdeinit5_shutdown /usr/bin/kdeinit5_wrapper
Coś się zaczyna:
audit: type=1400 audit(1549543408.304:5931): apparmor="DENIED" operation="exec" profile="/usr/bin/kdeinit5" name="/usr/lib64/libexec/kf5/klauncher" pid=28499 comm="klauncher" requested_mask="x" denied_mask="x" fsuid=1001 ouid=0
Ostatnio edytowany przez Jacekalex (2019-02-07 13:45:55)
Offline
Profil kdeinit5 rośnie w oczach:
# Last Modified: Thu Feb 7 14:04:52 2019 #include <tunables/global> /usr/bin/kdeinit5 { #include <abstractions/X> #include <abstractions/base> #include <abstractions/dbus> #include <abstractions/gnome> #include <abstractions/nameservice> #include <abstractions/openssl> network netlink dgram, network netlink raw, signal receive set=term peer=/usr/bin/akregator, unix, /dev/dri/ r, /proc/sys/kernel/core_pattern r, /sys/devices/**/device r, /sys/devices/**/uevent r, /sys/devices/**/vendor r, /usr/bin/kdeinit5 mr, /usr/lib64/libexec/kf5/* pix, /usr/lib{,32,64}/** mr, owner /dev/shm/.org.chromium.Chromium.* rw, owner /home/*/.cache/** rw, owner /home/*/.cache/mesa_shader_cache/index rw, owner /home/*/.compose-cache/** w, owner /home/*/.config/kdeglobals r, owner /home/*/.config/kio_httprc r, owner /home/*/.config/ksslcertificatemanager r, owner /proc/*/cmdline r, owner /var/run/user/*/*-socket rw, owner /var/run/user/*/kdeinit5* rw, owner /var/run/user/*/kio_http_cache_cleaner rw, owner /var/run/user/*/* lrw, }
Ostatnio edytowany przez Jacekalex (2019-02-07 14:12:12)
Offline
No ja kdeinit4 i kdeinit5 odpalam na starcie openbox'a i to na samym początku, tak by mi ich nic nie odpaliło, bo potem są problemy z regułami a profilach AA. A co do profili AA dla kdeinit, to daj sobie spokój. xD Ja kiedyś próbowałem zamknąć kdeinit4 i kdeinit5 i w końcu chciało dostęp do wszystkiego, to se dałem siana. :] Jeśli masz appki kde i korzystasz z nich, to prędzej czy później u ciebie też zachce dostęp do wszystkiego. xD
Ostatnio edytowany przez morfik (2019-02-07 15:51:51)
Offline
Ja pomalutku zbliżam się do full-system-policy, także mogę dać do wszystkiego
ale z wyjątkiem private-files, i np zabronić setuid i setgid i parę innych podejrzanych akcji.
I to i tak będzie kopernikańska zmiana.
To akurat nie problem, tak chyba muszę zrobić w profilu do sudo/su, do basha, pythona, perla i kilku innych.
Jestem na podobne scenariusze przygotowany od dawna.
Z KDE to mam nie tyle appki, tylko poważnie biorę pod uwagę Plasmę po migracji na Waylanda.
W Gtk4 i Mate na Nvidii z Waylandem wierzę średnio, a obecny Mate na Gtk2 działa grzecznie ale tylko na Xorgu.
Ostatnio edytowany przez Jacekalex (2019-02-07 20:38:44)
Offline
Strony: 1
Time (s) | Query |
---|---|
0.00010 | SET CHARSET latin2 |
0.00004 | SET NAMES latin2 |
0.00102 | 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='18.191.178.16' WHERE u.id=1 |
0.00059 | REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '18.191.178.16', 1732363308) |
0.00045 | SELECT * FROM punbb_online WHERE logged<1732363008 |
0.00044 | SELECT topic_id FROM punbb_posts WHERE id=322953 |
0.00006 | SELECT id FROM punbb_posts WHERE topic_id=30832 ORDER BY posted |
0.00055 | 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=30832 AND t.moved_to IS NULL |
0.00006 | SELECT search_for, replace_with FROM punbb_censoring |
0.00131 | 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=30832 ORDER BY p.id LIMIT 0,25 |
0.00080 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=30832 |
Total query time: 0.00542 s |