Przeglądając dział „Propozycje – NND” na forum trafiłem na topic „logowanie userow” , poczytałem i doszedłem do wniosku, że „to” się da zrobić. Czy się dało? – to się jeszcze okaże
Chciałbym, abyście zweryfikowali, ocenili, przeanalizowali pomysł zabezpieczenia sieci, a w sumie netu. To co za chwilę napiszę będzie zawierało w sobie opis pomysłu, trochę HOWTO i po części trochę FAQ.
Pomysł składa się z:
-skryptu
-kluczowych elementów docelowych: netstat (NIE netstat-nat), iptables
-klienta SSH
-paru modyfikacji/konfiguracji na serwerze
-paru zależności
Skrypt:
Tworzy nowy łańcuch o nazwie SECURE w tablicy filter, w łańcuchu FORWARD (łańcuch w łańcuchu ? – jakoś tak
, nie jestem biegły w iptables)
Zadaniem skryptu jest sprawdzanie userów aktywnych (netstat –n), połączonych poprzez klienta ssh i blokowanie ich taką regułką:
Zależności:
Skrypt sprawdza np. co 1 minute (odpalany z crona), czy user jest aktywny, jeśli jest to nic nie robi, jeśli nie jest, to blokuje mu wszystkie porty oprócz portu niezbędnego do połączenia z daemonem sshd.
Skrypt wystawie i opisze publicznie, po ew. przychylnej weryfikacji całego pomysłu.
Klient SSH:
Program o nazwie Bitvise Tunnelier (o absurdalnej, lecz niegroźnej ikonce w tray). Darmowy tylko dla indywidualnego użytku (w naszym przypadku każdy user używałby programu indywidualnie, czyli zgodnie z licencją
)Zadaniem klienta jest połączenie się z serwerem automatycznie przy starcie systemu operacyjnego (windows), zalogowanie się automtycznie i w razie utraty połączenia, wznowienie go (reconnect) po określonej przez nas liczbie sekund (w moim przypadku 28sekund, aby zmieścić się 2x w minucie, gdy skrypt wykonywany jest co 1 minute)
Mówiąc krótko w gre wchodzi tylko i wyłącznie pełna automatyka.
No oki, więc czas to wszystko zebrać do kupy, czyli: „No dobra, ale jak to działa ?”
Idea begin:
User nieaktywny jest zablokowany przez skrypt np.
iptables -t filter -A SECURE -s 192.168.0.10 -p tcp --dport ! 22 -j DROP
Jest zablokowany ponieważ netstat –n nie pokazał połączenia nawiązanego o stanie ESTABLISHED dla usera o IP: 192.168.0.10, na porcie 22 (ssh).
User włącza kompa, uruchamia się program Bitvise Tunnelier automatycznie łączy się z serwerem poprzez login i hasło (każdy user ma swoje konto na serwerze) i w tym momencie odblokowuje sobie Internet poprzez regułke:
/usr/bin/sudo /usr/sbin/iptables -t filter -D SECURE -s 192.168.0.10 -p tcp --dport ! 22 -j DROP.
Po wyłączeniu kompa/wylogowaniu się z serwera, w momencie odpalenia skryptu IP: 192.168.0.10 ponownie zostaje zablokowane. W wypadku odpalania skryptu co minute, staje się to w przedziale 1-59sekund. I właśnie tyle też sekund miałby ew. wardriver na wbicie się do sieci i nacieszenie się netem
, po tym czasie mógłby sobie co najwyżej pingi popuszczać o ile nie zablokowalibyśmy też protokołu icmp.„Wszystko ok., ale przecież user ma dostęp do shella no i do iptables na prawach roota poprzez sudo !?”
User praktycznie nie ma dostępu do shella.
Po koleji:
Dodajemy grupę o nazwie secure:
groupadd secure.
Edytujemy plik sudoers, dopisujemy w nim:
%secure ALL=NOPASSWD:/usr/sbin/iptables
czyli wszyscy, którzy należą do grupy secure mają dostęp poprzez sudo do iptables na prawach roota.
Dodajemy usera: useradd
Login – heniu
grupa – secure
shell
hasło – xxx.
Jako shell podajemy /katalog/domowy_usera/rbash (rbash – nazwa pliku, może być jakakolwiek), np. /home/secure/heniu/rbash.
W katalogu domowym usera tworzymy plik o nazwie rbash (chmod 755), edytujemy i wpisujemy:
#!/bin/sh
/usr/bin/sudo /usr/sbin/iptables -t filter -D SECURE -s 192.168.0.10 -p tcp --dport ! 22 -j DROP
exit
/usr/bin/sudo /usr/sbin/iptables -t filter -D SECURE -s 192.168.0.10 -p tcp --dport ! 22 -j DROP
exit
User tylko odblokowuje sobie net po czym konsola się zamyka (mgnienie okienka konsoli).
Zestaw dla usera:
3 pliki:
autostart.reg (wpis do rejestru) – plik który, user musiałby uruchomić, aby program odpalał się automatycznie przy starcie systemu. Plik jest potrzebny, ponieważ program niestety nie ma zaimplementowanej opcji autostartu więc używając komendy –loginOnStartup w rejestrze uruchomi się automagicznie.
Tunnelier-Inst.exe (4.12mb) – instalka programu, program zajmuje ok. 15mb po zainstalowaniu, czyli 16mb wolnego miejsca na jakiejś partycji. Program u mnie pożera średnio ok. 12xx Kilobajtów pamięci.
profile.tlp – profil usera, czyli wszystkie ustawienia programu wraz z (UWAGA) zakodowanym hasłem do konta na serwerze. Więc nawet user nie zna hasła do konta, bo po co
„Czemu jakiś Bitvise Tunnelier, a nie powszechnie używany Putty ?”
Wszystko oczywiście zaczęło się od putty, kombinacji była masa, wraz z kluczami prywatnymi (RSA, DSA), publicznymi, agentami, generatorami kluczy kończąc na próbie użycia opcji „Remote command”. (nawet znalazłem w necie PuttyTray, putty, które na starcie schodzi do traya
)
Krótko: Putty nie, bo putty nie ma opcji reconnecta, czyli automatycznego wznawiania połączenia po padzie.
Wyobraźmy sobie sytuacje, że user w nocy ściąga coś tam. Następuje chwilowy zanik napięcia w pomieszczeniu gdzie jest serwer (nie mamy ups-a), serwer się restartuje, lub sami restartujemy serwer, a putty u usera już się nie łączy z serwerem, więc skrypt blokuje usera = porażka.
Jak pisałem wcześniej, tylko pełna automatyka wchodzi w gre.
Póki co opcja „reconnect” w putty jest na stronie domowej putty w podstronie wishlist (czyli w liście życzeń) i to w dziale „fun” – nie wiem czemu J (pewnie dlatego, że putty nie zostało stworzone do spełniania potrzeb moich chorych pomysłów
).
„Dlaczego akurat SSH ?”
Dlatego, że połączenie jest szyfrowane.
„Dlaczego nie netstat-nat ?”
Dlatego nie, bo netstat-nat kłamie, a dokładnie przekłamuje (czasami). Czasem gdy sprawdzam poprzez „neststat-nat –n –L” czy połączenie jest nawiązane, mimo tego że jest, netstat-nat nic nie pokazuje. Chyba nie muszę tłumaczyć co się stanie, gdy pomimo połączenia netstat-nat nic nie pokaże, w momencie odpalenia się skryptu. Tak bynajmniej wynika z przeprowadzonych przeze mnie testów.
Natomiast netstat jest nieugięty w tej kwestii. (Na wykorzystanie netstata nakierował mnie –MW- dzięki Mariusz
)
[/quote]
