Ograniczanie dostępu do sieci kontenera Docker

Jestem w trakcie tworzenia kontenera Docker tylko do SFTP , który będzie używany przez wiele osób wyłącznie w celu przesyłania plików i zarządzania nimi we własnym chrootśrodowisku ed.

Na papierze jest to całkiem bezpieczne: wyłączę każdą formę bashlogowania i nie będę uruchamiał w tym procesie żadnego innego procesu. Chciałbym jednak trochę to wzmocnić:

Chcę uniemożliwić temu kontenerowi dostęp do Internetu od wewnątrz, z wyjątkiem tego, że jest to serwer SFTP.

Żeby było jasne: wiem, jak uniemożliwić światowi zewnętrznemu dostęp do mojego kontenera - mogę skonfigurować iptablesreguły przychodzące i ujawnić tylko port SFTP w moim poleceniu uruchomienia dokera.

Chciałbym jednak, aby następujące polecenie (jako przykład) nie powiodło się, gdy uruchomiono je w kontenerze:

curl google.com

Moim zamiarem jest zmniejszenie ilości szkód, które zhakowany pojemnik może wyrządzić (nie można go użyć do wysyłania spamu itp.).

Nadal sensowne jest umieszczanie reguł wejściowych w instancji dokera, aby pomóc odeprzeć ataki, ale będziesz musiał ograniczyć dostęp wychodzący (Internet) z dowolnego routera, z którym łączy się obraz dokera. Powodem tego jest to, że jeśli spróbujesz zablokować dostęp wychodzący za pomocą reguł zapory w Twojej instancji, wówczas jeśli instancja zostanie naruszona, reguły te mogą zostać usunięte przez atakującego. Blokując wyjście przez router instancji, blokujesz dostęp wychodzący nawet w przypadku kompromisu - osoba atakująca musiałaby również naruszyć router.

Ok, więc po otrzymaniu komentarza wyjaśniającego, że filtrowanie było przeznaczone dla hosta kontenera, jest trochę bardziej jasne, co próbuje się osiągnąć. W takim przypadku na hoście dodasz kilka reguł podobnych do tego:

iptables -A FORWARD -s lo.cal.sub.net -d con.tai.ner.ip -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -d lo.cal.sub.net -j ACCEPT
iptables -A FORWARD -s ! lo.cal.sub.net -d con.tai.ner.ip -p tcp --dport sftp -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -d ! lo.cal.sub.net -p tcp --sport sftp -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -m state --state related,established -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -j DROP

Dwie pierwsze zasady dotyczą dostępu między hostem a kontenerem. Trzecia reguła mówi (z grubsza), że wszystko, co nie jest podsiecią hosta skierowaną na SFTP, jest po prostu w porządku; czwarta jest regułą wychodzącą, która jest zasadniczo bliźniakiem trzeciej; piąta reguła to catch-all (w przypadku użycia innych powiązanych portów), chociaż nie powinno być to potrzebne, prawdopodobnie można je usunąć; ostatnia reguła to magia, która uniemożliwia dostęp do czegokolwiek innego niż podsieć hosta. Ponieważ dostęp jest podany w kilku pierwszych regułach, nigdy się nie uruchomi, chyba że żadna z powyższych reguł nie będzie miała zastosowania, w którym to przypadku mówimy: „nie dbamy o to, czego chcesz, nie pasujesz do niczego, na co jesteś zatwierdzony, więc nie możesz się stąd dostać ". Ruch przychodzący z zewnątrz będzie zgodny z 3. i 4. zasadą.

To nie jest tak naprawdę problem związany z dokerem. Istnieje kilka sposobów rozwiązania tego problemu.

1. Użyj iptablesreguł stanowych , aby zezwolić na połączenia przychodzące i powiązany / ustalony ruch, a następnie zablokuj wszystko inne.

2. Użyj usługi tylko sftp, takiej jak ProFTPD, która nie jest w stanie uruchomić powłoki.

Ogólnie rzecz biorąc, jeśli nie pozwalasz użytkownikom uzyskać powłoki i nie pozwalasz im uruchamiać programów z poziomu kontenera, nie musisz się tym martwić.

To tylko szybka burza mózgów i jeszcze jej nie testowałem. Będziesz chciał sprawdzić go w laboratorium przed zabraniem go do produkcji.

Aby uniemożliwić ruch wychodzący na portach innych niż SSH (SFTP) i porty internetowe, możesz zastosować zasady za pośrednictwem IPTABLES lub innej zapory ogniowej Layer4 do ruchu DROP lub REJECT pochodzącego z segmentu używanego przez kontenery dokujące przeznaczone na 0.0.0.0/0, z wyjątkiem sytuacji, gdy jest to miejsce docelowe Port to TCP22.

Aby rozwiązać problem braku dostępu do miejsc w Internecie, możesz spróbować skonfigurować instancję serwera proxy do filtrowania / buforowania, takiego jak kałamarnica lub bluecoat, który nasłuchuje na interfejsie dokera 0 i używa droga defaltowana przez gospodarza, aby dostać się do Internetu. Stamtąd można zastosować zasady oparte na wielu kryteriach, a także zaoszczędzić wykorzystanie sieci przez buforowanie zawartości statycznej. Możesz użyć NAT (myślę, że IPTABLES i Masquerade zapewniają to w Linuksie) na maszynie hosta, aby wymusić użycie proxy w sposób transparentny (opisałem to w odpowiedzi na Chcę tylko proxy HTTP, ale nie jestem pewien, co zrobić zrobić z ruchem HTTPS ). Oznacza to, że mają powód, aby wejść do sieci w pierwszej kolejności, zgodnie z zasadami firmy.

Ze względu na naturę SSH (na której oparty jest SFTP), nie będziesz w stanie zapewnić ograniczenia ruchu do przenoszenia plików, chyba że wdrożysz zasadę, zgodnie z którą kontenery mogą korzystać tylko z dostarczonych przez Ciebie par kluczy. Jest to dobre dla Ciebie, ponieważ daje ci pewne „ Nie miałem widoczności ani kontroli nad przesyłanymi plikami„obrona, jeśli jeden z twoich klientów przeniesie coś nielegalnego (np. naruszenie praw własności intelektualnej lub wykorzysta twoją usługę do przefiltrowania informacji opatrzonych etykietą klasyfikacyjną lub zamieniają CP), jeśli zostaniesz postawiony przed sądem za coś, co robią Twoi klienci (pomyśl o podejrzeniu status wspólnego operatora dla operatorów telekomunikacyjnych). Jest to złe dla ciebie, ponieważ nie możesz buforować często ponownie przesyłanych, niezmienionych plików oraz ponieważ wszelkie zasady, które zapisujesz w umowie z klientami, będą zasadniczo niemożliwe do wyegzekwowania za pomocą środków technicznych.