Peter Holmes
0
5061
431
Hosting współdzielony. To tania opcja, prawda? W przypadku ogromnej grupy ludności to wszystko, czego kiedykolwiek będą potrzebować do hostowania swojej witryny lub aplikacji internetowej. A jeśli dobrze to zrobisz, hosting współdzielony jest skalowalny, szybki i bezpieczny.
Ale co się stanie, gdy nie zostanie to zrobione dobrze?
Cóż, wtedy zaczynają wkradać się niebezpieczne problemy bezpieczeństwa. To wtedy istnieje ryzyko, że Twoja witryna zostanie uszkodzona lub wyciek z prywatnych danych. Ale nie martw się. Zdecydowana większość hostów internetowych ma przyzwoite środki bezpieczeństwa. To tylko gospodarze z piwnicy na okazje, których trzeba się wystrzegać.
Zalecamy współdzielony hosting InMotion Hosting z pamięcią SSD.
Omówimy problemy bezpieczeństwa związane z udostępnianiem hostingu. Ale najpierw porozmawiajmy o tym, co zapewnia bezpieczeństwo wspólnej platformy hostingowej.
Co sprawia, że bezpieczny host internetowy
Istnieje kilka wyjątkowych kwestii bezpieczeństwa, które należy wziąć pod uwagę w odniesieniu do hostingu współdzielonego.
- Każdy użytkownik na serwerze powinien być odizolowany od innych użytkowników i nie powinien mieć dostępu do plików innych użytkowników ani ich modyfikować.
- Luka w zabezpieczeniach logiki witryny hostowanej na serwerze nie powinna mieć wpływu na innych użytkowników.
- Serwer jest regularnie aktualizowany, aktualizowany i monitorowany w celu rozwiązania problemów związanych z bezpieczeństwem architektury.
- Każdy użytkownik powinien mieć własny izolowany dostęp do bazy danych i nie powinien mieć możliwości wprowadzania zmian w przechowywanych rekordach ani uprawnień do tabeli innych użytkowników.
Ponownie, większość hostów internetowych spełnia te wymagania dotyczące udostępnianych ofert. Ale jeśli szukasz hostingu dla wielu witryn na jednym serwerze lub zastanawiasz się, jak się układa Twoja firma hostingowa, a nawet myślisz o uruchomieniu własnej firmy hostingowej i chcesz dowiedzieć się, jak zabezpieczyć swoich użytkowników, przeczytaj ten artykuł. na.
Ale po pierwsze, zastrzeżenie
Zanim przejdziemy do sedna patrzenia na typowe ataki przeprowadzane na współdzielonym hostingu, chcę tylko stwierdzić, że ten post nie będzie (i nie powinien być traktowany jako) wyczerpującą listą potencjalnych problemów bezpieczeństwa.
Jednym słowem bezpieczeństwo jest duże. Istnieje wiele sposobów na skompromitowanie witryny. Jest to dwa razy większe w przypadku hostingu dzielonego. Pokrycie ich w jednym artykule nigdy nie było na kartach.
Jeśli jesteś paranoikiem w kwestii swojego bezpieczeństwa, zdobądź VPS lub serwer dedykowany. Są to środowiska, w których masz (w przeważającej części) absolutną kontrolę nad tym, co się dzieje. Jeśli nie masz pewności co do różnych rodzajów hostingu, zapoznaj się z tym postem Różne formy hostingu witryny wyjaśnione [Technologia wyjaśniona] Różne formy hostingu witryny wyjaśnione [Technologia wyjaśniona] od mojego kolegi, Jamesa Bruce'a.
Powinienem również podkreślić, że tego postu nie należy interpretować jako ataku na dzielony hosting. Jest to raczej czysto akademickie spojrzenie na kwestie bezpieczeństwa związane z tą kategorią hostingu.
Directory Traversal
Zacznijmy od ataków typu „traversal”. Ten rodzaj ataku umożliwia dostęp do plików i katalogów przechowywanych poza katalogiem głównym.
W prostym angielskim? Wyobraźmy sobie, że Alice i Bob używają tego samego serwera do hostowania swoich stron internetowych. Pliki Alice są przechowywane w / var / www / alice, natomiast dokumenty Boba można znaleźć w / var / www / bob. Ponadto udawajmy, że na serwerze jest inny folder (/ usr / crappyhosting / myfolder), który zawiera niezaszyfrowany plik tekstowy (nazwiemy go pwd.txt) zawierający systemowe nazwy użytkownika i hasła.
Do tej pory ze mną? Dobry. Teraz wyobraźmy sobie, że strona internetowa Boba zawiera pliki PDF generowane lokalnie, a plik lokalny jest przywoływany w adresie URL. Coś jak:
http://example.com/file?=report.pdf
Co by się stało, gdybym zastąpił plik „report.pdf” niektórymi parametrami UNIX, które zmieniają katalog?
http://example.com/file?=… / alice /
Jeśli serwer jest niepoprawnie skonfigurowany, pozwoli to zobaczyć katalog główny Alice. Interesujące, ale o wiele bardziej interesuje nas ta soczysta teczka paszportowa. Hasła Accio!
http://example.com/file?=… /… /… /… /usr/crappyhosting/myfolder/pwd.txt
To naprawdę takie proste. Ale jak sobie z tym poradzić? To łatwe.
Słyszałem kiedyś o mało znanym narzędziu Linux o nazwie chroot? Prawdopodobnie już zgadłeś, co to robi. Ustawia katalog główny Linux / UNIX na dowolny folder, uniemożliwiając użytkownikom wyjście z niego. Skutecznie zatrzymuje ataki przechodzenia przez katalog na ich ścieżkę.
Trudno powiedzieć, czy Twój gospodarz ma to miejsce bez łamania prawa. W końcu, aby to przetestować, będziesz uzyskiwać dostęp do systemów i plików, do których nie masz uprawnień. Mając to na uwadze, być może warto byłoby porozmawiać z usługodawcą internetowym i dowiedzieć się, w jaki sposób izolują użytkowników od siebie.
Czy prowadzisz własny udostępniony serwer hostingowy i nie używasz chroot do ochrony użytkowników? Wprawdzie chrootowanie środowiska może być trudne. Na szczęście istnieje wiele wtyczek, które to ułatwiają. W szczególności spójrz na mod_chroot.
Wstrzyknięcie polecenia
Wróćmy do Alice i Boba. Wiemy, że aplikacja internetowa Boba ma kilka… hmm… problemów z bezpieczeństwem. Jedną z nich jest luka polegająca na wstrzykiwaniu poleceń, która pozwala na uruchamianie dowolnych poleceń systemowych. Krótki przewodnik, aby rozpocząć pracę z linią poleceń Linuksa. Krótki przewodnik, aby rozpocząć pracę z linią poleceń Linuksa. Polecenia w Linuksie można wykonywać za pomocą niesamowitych rzeczy i naprawdę nie jest trudno się uczyć. .
Witryna Boba umożliwia uruchomienie zapytania whois w innej witrynie, która jest następnie wyświetlana w przeglądarce. Istnieje standardowe pole wprowadzania HTML, które akceptuje nazwę domeny, a następnie uruchamia komendę systemową whois. Ta komenda jest wykonywana przez wywołanie komendy system () PHP.
Co by się stało, gdyby ktoś wprowadził następującą wartość?
example.com && cd… / alice / && rm index.html
Rozbijmy to. Niektóre z tych zagadnień mogą być ci znane, jeśli przeczytałeś nasz „Przewodnik dla Linuksa” Przewodnik dla Linuksa Przewodnik dla Linuxa Przewodnik dla Linuxa dla początkujących! Prawdopodobnie słyszałeś o Linuksie, darmowym systemie operacyjnym typu open source, który naciska na Microsoft. e-book, który wcześniej opublikowaliśmy w 2010 r., lub przejrzał nasz arkusz poleceń Linuksa.
Po pierwsze, uruchomi zapytanie whois na example.com. Następnie zmieniłby bieżący katalog roboczy na katalog główny Alice. Następnie usunąłby plik o nazwie „index.html”, który jest stroną indeksu w jej witrynie internetowej. To nie jest dobrze. Nie proszę pana.
Zatem, jako administratorzy systemu, jak możemy temu zaradzić? Cóż, wracając do poprzedniego przykładu, zawsze możemy umieścić każdego użytkownika we własnym odizolowanym, odkażonym, chrootowanym środowisku.
Możemy również podejść do tego z poziomu języka. Możliwe jest (choć może to zepsuć) globalne usunięcie deklaracji funkcji z języków. To znaczy, możliwe jest usunięcie funkcjonalności z języków, do których użytkownicy mają dostęp.
Patrząc w szczególności na PHP, możesz usunąć funkcjonalność za pomocą Runkit - oficjalnego zestawu narzędzi PHP do modyfikowania funkcjonalności języka. Istnieje bogactwo dokumentacji. Przeczytaj w to.
Możesz także zmodyfikować plik konfiguracyjny PHP (php.ini), aby wyłączyć funkcje często wykorzystywane przez hakerów. Aby to zrobić, otwórz terminal na serwerze i otwórz plik php.ini w edytorze tekstu. Lubię korzystać z VIM, ale NANO jest również do przyjęcia.
Znajdź linię zaczynającą się od disable_functions i dodaj definicje funkcji, które chcesz zablokować. W tym przypadku byłoby to exec, shell_exec i system, chociaż warto zauważyć, że istnieją inne wbudowane funkcje, które są wykorzystywane przez hakerów.
disable_functions = exec, shell_exec, system
Ataki oparte na języku i tłumaczach
Spójrzmy więc na PHP. To jest język, który napędza zaskakującą liczbę stron internetowych. Ma też wiele osobliwości i dziwnych zachowań. Lubię to.
PHP jest zwykle używane w połączeniu z serwerem WWW Apache. W większości przypadków przy tej konfiguracji nie można załadować wielu wersji języka.
Dlaczego to jest problem? Wyobraźmy sobie, że aplikacja internetowa Boba została pierwotnie zbudowana w 2002 roku. To już dawno. Wróciło, kiedy Michelle Branch wciąż znajdowała się na szczycie list przebojów, Michael Jordan wciąż grał w Washington Wizards, a PHP był zupełnie innym językiem.
Ale strona Boba nadal działa! Wykorzystuje całą masę wycofanych i przestarzałych funkcji PHP, ale działa! Korzystanie z nowoczesnej wersji PHP skutecznie zniszczyłoby witrynę Boba i dlaczego Bob powinien przepisać swoją stronę internetową, aby zaspokoić kaprysy swojego hosta?
To powinno dać ci wyobrażenie o dylemacie, przed którym stoją niektórzy gospodarze. Muszą zachować równowagę, utrzymując bezpieczną pod względem architektonicznym i bezpieczną usługę, jednocześnie utrzymując ją w harmonii z zapewnieniem zadowolenia płacącym klientom.
W rezultacie często zdarza się, że mniejsze, niezależne hosty używają starszych wersji interpretera PHP (lub dowolnego innego języka).
Często zdarza się, że mniejsze, niezależne hosty używają starszych wersji PHP, potencjalnie narażając użytkowników na zagrożenia bezpieczeństwa.
Dlaczego to jest złe? Po pierwsze, naraziłby użytkowników na szereg zagrożeń bezpieczeństwa. Podobnie jak większość głównych pakietów oprogramowania, PHP jest stale aktualizowany, aby zaradzić mnóstwu luk w zabezpieczeniach, które są ciągle wykrywane (i ujawniane).
Co więcej, oznacza to, że użytkownicy nie mogą korzystać z najnowszych (i najlepszych) funkcji językowych. Oznacza to również, że funkcje, które zostały przestarzałe z jakiegoś powodu, pozostają. W przypadku języka programowania PHP obejmuje to strasznie straszne (i ostatnio przestarzałe) funkcje mysql_, które są używane do interakcji z systemem relacyjnych baz danych MySQL oraz dl (), który pozwala użytkownikom importować własne rozszerzenia językowe.
Jako użytkownik powinieneś być w stanie zobaczyć, która wersja tłumacza działa w Twojej usłudze. Jeśli jest nieaktualny lub zawiera wiele luk w zabezpieczeniach, skontaktuj się z hostem.
Co z sysadminami? Masz tutaj kilka opcji. Pierwszym (i najbardziej obiecującym) jest użycie Dockera dla każdego z użytkowników. Docker pozwala na jednoczesne uruchamianie wielu izolowanych środowisk, podobnie jak maszyna wirtualna, aczkolwiek bez konieczności uruchamiania innego systemu operacyjnego. W rezultacie jest to szybkie. Naprawdę bardzo szybko.
W prostym angielskim? Możesz uruchomić najnowszy i największy najnowocześniejszy interpreter dla większości swoich użytkowników, podczas gdy klienci korzystający ze starych aplikacji korzystających ze starych, przestarzałych tłumaczy robią to bez narażania innych użytkowników.
Ma to również tę zaletę, że jest niezależny od języka. PHP, Python, Ruby. Cokolwiek. To wszystko jest takie samo.
Nie miej koszmarów.
Ten post miał na celu zrobienie kilku rzeczy. Po pierwsze, miało to na celu zwrócenie uwagi na liczbę problemów bezpieczeństwa, z którymi muszą zmagać się firmy hostingowe, aby zapewnić bezpieczeństwo swoich klientów i ich danych.
Jego celem było również pokazanie, w jaki sposób witryny hostowane na tym samym serwerze mogą wpływać na siebie nawzajem. Chcesz to zrobić? Zacznij przestrzegać dobrych, bezpiecznych standardów kodowania. W szczególności rozpocznij dezynfekcję danych wejściowych zarówno na interfejsie, jak i na zapleczu.
Dobry początek to nowa funkcja sprawdzania poprawności formularza HTML5. Mówiliśmy o tym wcześniej w naszym przewodniku po HTML5. Wspólnie możemy sprawić, że strony internetowe będą bezpieczniejsze, będąc lepszymi, bardziej sumiennymi programistami.
Jak zawsze jestem gotowy usłyszeć twoje myśli. Dodaj mi komentarz poniżej.
Kredyt na zdjęcie: Każdy potrzebuje hakera (Alexandre Dulaunoy), naklejki na oknie taksówki (Cory Doctorow), serwerowni (Torkild Retvedt), książek i czasopism z systemem Linux (nauczycielka_biblioteki), słonia PHP (Markus Tacker)