4 odpowiedzi na ten temat

[lukasamd]

Witam,
aktualnie używam FTP po SSL (poprzez vsftpd) lecz wydaje mi się to zbędne skoro jest SFTP.
Nie chcę robić pełnego chroota bo jestem znacznie zbyt zielony jak na wszystkie operacje które trzeba przy nim wykonać.
Poza tym, chodzi tylko o bezpieczne wysyłanie / pobieranie plików, nic więcej.

Poszukałem, znalazłem informacje o rssh - działa, lecz użytkownicy mogą wychodzić poza swój katalog, a chcę na ile się da im to ograniczyć
Potem znalazłem informacje o chroot w ustawieniach ssh więc wygląda to tak:

Match user testowiec
ChrootDirectory /home/testowiec
ForceCommand internal-sftp
AllowTcpForwarding no
X11Forwarding no

Działa, user jest "zamknięty" w swoim katalogu, ale jak to wygląda z punktu widzenia bezpieczeństwa i powłoki?
Przy vsftpd mogłem stosować dla tego użytkownika "powłokę" /bin/false, dla rssh było to /usr/bin/rssh, zaś w ostatecznym rozwiązaniu jest /usr/bash (gdy został zapis z rssh to nie działało).
Czy to nie otwiera jakichś "furtek" i niechcianych dla mnie możliwości dla użytkownika? Przy próbie połączenia po ssh np. przez PuTTy od razu po podaniu hasła serwer się rozłącza, bo o ile dobrze rozumiem, zawsze wymusza używanie sftp i inne polecenia również się do niego sprowadzają.
Wolałbym się jednak upewnić, czy to oby na pewno bezpieczne rozwiązanie.

[samu]

Jest to dość bezpieczne rozwiązanie, jednak jak to mawiał znajomy - zawsze sekjurity by cebulka.

Z Chroota dało się łatwo wyrwać w przeszłości (na czystym jajku linuksa można do tej pory), więc oprócz tego dołożyłbym jakiś lokalny MAC - domyślam się że to linux. RBAC i do przodu, grsec to też obowiązek. Na BSD ugidfw + odpowiednie sysctlki do podtunowania.

A propos:

Match group sftponly
		 ChrootDirectory /home/%u
		 X11Forwarding no
		 AllowTcpForwarding no
		 ForceCommand internal-sftp

No bo chyba nie chcesz za każdym razem dopisywać użytkowników do sshd_conf ;-)

[lukasamd]

Ok, dzięki za info.
Chodzi mi w zasadzie tylko o przesyłanie plików, więc co jest lepsze - takie rozwiązanie, czy pozostawienie FTPS?
Tak jak pisałem, używam vsftpd i FTPS - port zmieniony, przyjmuje tylko szyfrowane po TLS, czysty FTP jest wyłączony.
Przejrzałem już multum stron opisujących różnice SFTP <-> FTPS, lecz nigdzie nie ma czarno na białym napisane, czy któryś jest / nie jest bezpieczniejszy i dlaczego.

Zastanawiam się, bo w zasadzie vsftpd jest bardzo lekki i zupełnie nieodczuwalny. Mogę dać użytkownikom dostęp do shella i potem ograniczać chrootem i innymi rzeczami, lub też nie dawać i zostawić FTPS, o ile jest bezpieczny.

Ten post był edytowany przez lukasamd dnia: 07 luty 2012 - 14:13

[samu]

Dzięki vfstpd masz swego rodzaju rozgraniczenie pomiędzy użytkownikami systemowymi, a "wirtualnymi" - jeden klik w bazie danych i użytkownika nie ma. Z drugiej jednak strony, jest to kolejny daemon, który musisz audytować, a openssh "i tak" masz już w systemie i z niego korzystasz.

Moim zdaniem wszystko zależy od skali. Ja jednak osobiście preferuję SFTP - ale jak pisałem, niezależnie od tego które rozwiązanie wybierzesz i tak powinieneś zadbać o lokalny MAC.

[_MK_]

Rozwiązanie z SFTP które opisałeś ma jedną dość istotną wadę - port na którym słucha openssh musisz wystawić dla świata. Rozumiem, że przez "to samo SSH" dostajesz się na swoje konto z którego potem administrujesz maszyną?

Wszystko zależy od przyjętego modelu bezpieczeństwa, ale jeśli już mówimy o poprawianiu "security" to dobrą praktyką jest otworzyć dostęp do SSH jedynie dla tych którzy muszą go naprawdę mieć - samych administratorów. Można zdefiniować ograniczoną pulę "zaufanych" adresów IP mających dostęp do portu na którym słucha SSH lub stosować np. port knocking (http://doorman.sourceforge.net/ ).

Stosując openssh jako system do bezpiecznej transmisji plików pokusiłbym się o stworzenie separowanego środowiska (np. oddzielny jail/chroot) dla którego zakładane byłyby konta z powłoką jedynie dla SCP lub jeśli nie byłoby to możliwe dla kont z powłoką inną niż SCP stosowałbym autentykację jedynie po certyfikatach.

Ps.: Poza wspomnianym rssh spotkałem się jeszcze z powłoką "scponly" (http://sourceforge.n...ojects/scponly/), sprawowało się nie najgorzej.