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/.
W plikach /etc/hosts.allow i /etc/hosts.deny można umieszczać politykę bezpieczeństwa odpowiedzialną za połączenia zdalne do usług lokalnych. W takim przypadku można dodać do pliku /etc/hosts.allow wpis:
sshd: 192.168.10.0/24
i jednocześnie do pliku /etc/hosts.deny to poniższe:
ALL:ALL EXCEPT localhost:DENNY
I na wypadek niezaładowania reguł iptables, tylko hosty z tej powyższej sieci będą mogły się logować na shella.
Pytanie jest jak ustalić nazwę, która się kryje pod sshd? Pierw myślałem, że to jest nazwa procesu i gdy chciałem limitować za jej pomocą połączenia do serwera dźwięku pulseaudio, okazało się, że wpisanie tutaj "pulseaudio" nie rozwiązuje problemu. Trzeba było dodać pulseaudio-native , a takiego procesu u mnie zwyczajnie nie ma. Zatem jak ustala się te nazwy?
Offline
dawno, dawno temu, w odległej galaktyce istniały programy, które zwracały na to uwagę. i istnieli rycerze jedi, którzy swymi świetlnymi mieczami każdy podejrzany pakiey odcinali przy samej głowie.
potem powstał ipchains...
potem powstał iptables...
...i dziś rycerze jedi siedzą w barze na tatooine i piją piwo...
Offline
cat /etc/services
Offline
@pasqdnik, /etc/services raczej nie, nie ma tam nawet sshd. Jest tylko ssh, a pulse* to już w ogóle. xD
@ethanak, ja bym ci radził uważnie przeczytać zdanie: "I na wypadek niezaładowania reguł iptables...". Ja jestem zwolennikiem wielopoziomowych zabezpieczeń. W przypadku gdy ci fw nawali z jakiegoś powodu, to muszą być inne mechanizmy ochrony, które będą bronić cnoty twojego PC i po to są min. te pliki /etc/hosts.* , które działają wbrew twojej "fantastycznej" opinii. xD
Offline
I na wypadek niezaładowania reguł iptables, tylko hosty z tej powyższej sieci będą mogły się logować na shella.
1. Chwilowo masz w zapasie NFtables, działa równolegle z Iptables, kiedyś go zastąpi, na razie działają szeregowo, jakbyś miał dodatkowy wirtualny router z FW po drodze.
2. Napisz może, jak udało Ci się nie załadować reguł Iptables, mnie się to przez 8 lat nie udało, także jestem ciekaw. :DDD
W razie czego możesz do startu sieci dodać, żeby przed podniesieniem sieci sprawdzał, czy są załadowane reguły FW, i w razie czego nie podniósł interfejsu - da się to oskrypcić.
Jakbyś chciał się bawić Grseciem, to tam masz RBAC, który zapewnia dodatkowego FW realizowanego przez Grsec, niezależnego od Iptables
i NFtables, działającego per/[user|grupa|subject].
Działa na razie tylko po IPv4, Ipv6 ma się pojawić w przyszłości (stan od 2011).
W SELinuxie też jest możliwość blokowania połączeń samym ACL, ale w tej chwili nie znam szczegółów.
Bindowanie na poziomie portów 1-1024 wymaga roota albo uprawnienia CAP_NET_BIND_SERVICE, CAP_NET_BROADCAST, CAP_NET_RAW - także da się to załatwić przez capabilities (setcap, getcap) albo np Apparmora, czy GRSEC-RBAC.
Także możliwości masz sporo.
Pozdro
;-)
Ostatnio edytowany przez Jacekalex (2015-11-11 21:01:18)
Offline
2363
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:27:00)
Offline
uzytkownikubunt napisał(-a):
Tak jak ethanak napisał, blokowanie przez te pliki to nie jest to, czego szukasz, jeśli chcesz mieć coś pewnego na wypadek niezaładowania reguł do iptables.
Po co piszesz w wątku, kiedy nie wnosisz do niego niczego nowego?
Windows 8.1 Update 3 64-bit & OpenBSD -current amd64
Obecnie w HDD nie mam żadnego systemu opartego o jądro Linux.
Trudno nie zauważyć. :D
Mnie Ubuntu przekonało do Gentusia, Ciebie do OpenBSD, niezłe to Ubuntu. :DDD
Offline
2. Napisz może, jak udało Ci się nie załadować reguł Iptables, mnie się to przez 8 lat nie udało, także jestem ciekaw. :DDD
Ja wiem, może powstał jakiś dependency loop i wyłączył akurat skrypt iptables z autostartu. xD Albo, np. ktoś odpalił skrypt iptables i zapomniał go włączyć w autostarcie. Może ktoś go świadomie wyłączył albo jakiś program nadpisał zdefiniowane już reguły swoimi, ustawiając przy tym politykę na ACCEPT. Różne rzeczy się zdarzają. xD
W razie czego możesz do startu sieci dodać, żeby przed podniesieniem sieci sprawdzał, czy są załadowane reguły FW, i w razie czego nie podniósł interfejsu - da się to oskrypcić.
Jeśli to miałaby być usługa systemowa, to raczej nie rozwiązuje to problemu, bo ona też może się nie podnieść z jakiegoś powodu. A jak nie usługa, to gdzie to określić?
Jakbyś chciał się bawić Grseciem, to tam masz RBAC, który zapewnia dodatkowego FW realizowanego przez Grsec, niezależnego od Iptables
i NFtables, działającego per/[user|grupa|subject].
Kiedyś się będę bawił ale jeszcze nie teraz.
Generalnie to mi zależy na tym by istniał jakiś dodatkowy mechanizm, który by zadziałał na wypadek problemów z FW, a ten /etc/hosts.* wydaje się całkiem przyzwoity. Przynajmniej działa. xD
a jesteś pewien że to zadziała poza inetd?
Poza czym?
Tak jak ethanak napisał, blokowanie przez te pliki to nie jest to, czego szukasz, jeśli chcesz mieć coś pewnego na wypadek niezaładowania reguł do iptables.
Przecie poprawnie blokują te pliki. Przynajmniej mi się nie udało połączyć ani z pulse ani z ssh. Także dlaczego ten mechanizm ma być zły?
Ostatnio edytowany przez morfik (2015-11-11 21:10:55)
Offline
Ehhz inetd ma kilka plików, z których sobie czyta konfigurację usług.
/etc/rpc
/etc/services
/etc/protocols
+ popularne nazwy demonów np sshd, tftp, ftp, telnet, finger etc.
I, tak jak piszą przedmówcy, poza inetd to nie bangla.
Offline
OK, jaka to jest sytuacja "poza inetd"?
Tak czytam i czytam o tym inetd i wyczytałem, że gdzieś tam kiedyś był inetd, potem go zastąpili xinetd i z tego co widzę, to ja u siebie nie mam zainstalowanego pakietu xinetd . Czy to jest sytuacja "poza inetd"? Jeśli tak, to te pliki działają. xD
Ostatnio edytowany przez morfik (2015-11-11 21:36:29)
Offline
2364
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:27:02)
Offline
Ja nie jestem programistą. Poza tym, jest bardzo prawdopodobne, że ktoś już zaprojektował odpowiedni mechanizm i zrobił to pewnie o wiele lepiej gdyby ja się za to wziął. xD
Offline
Jasny gwint, dodaj sobie w różnych miejscach skrypty dodające domyślne polityki blokowania w FW, i zawsze któryś ruszy.
Moduły FW wbuduj na sztywno w jajo, wtedy się nie zgubią, i gotowe.
Do tego chattr +i na wszystkie binarki i liby iptables, i też nie zgubisz.
Ani teoretycznie, ani praktycznie.
Ostatnio edytowany przez Jacekalex (2015-11-11 22:18:54)
Offline
Czy ta sytuacja "poza inetd" to występuje w przypadku niezainstalowanego pakietu xinted, czy nie. Bo w sumie to tylko to próbuje ustalić. xD Bo ja tego pakietu nie mam a polityka ustawiona w tych plikach /etc/hosts.* działa. :]
Offline