Czy zainstalowanie serwera produkcyjnego jest bezpieczne?

42

Podczas instalacji instancji mojego serwera wirtualnego wymagam budowy niektórych aplikacji make. Czy są jakieś zagrożenia bezpieczeństwa związane z makezainstalowaniem? Czy powinienem to wyczyścić przed wdrożeniem instancji?

Mam również gcckompilator na serwerze, którego używam do tworzenia aplikacji przed wdrożeniem.

security make gcc

— SK ”
źródło

4

Jeśli poczujesz się lepiej, każde oprogramowanie zainstalowane w dowolnym miejscu stwarza lukę.

— MDMoore313

1

A osoba z dostępem do powłoki użytkownika innego niż root do serwera mogłaby pobrać pakiet kompilatora „niezależny od dystrybucji” (.tar.gz), który nie będzie musiał być instalowany, więc ...

1

Czy to ja, czy kombinacja „czy to jest bezpieczne?” i „dostęp root” raczej niewygodny ?

— DNA

2

Jeśli masz już zainstalowany gcc, praktycznie nie ma sposobu, aby pogorszyć potencjalny problem z bezpieczeństwem.

— Shadur

1

@Shadur Jaką różnicę robi GCC? Jeśli użytkownik ma już dostęp do komputera, może w prosty sposób przesłać dowolną kopię gcc. W każdym razie gcc może być użyteczny dla nieuprzywilejowanych użytkowników i nie stanowi zagrożenia dla bezpieczeństwa, o ile nie uruchamiają go użytkownicy uprzywilejowani.

— Rzeczywistość

50

Niektórzy twierdzą, że obecność narzędzi programistycznych na maszynie produkcyjnej ułatwi życie atakującemu. Jest to jednak tak niewielka przeszkoda dla atakującego, że każdy inny argument za lub przeciw instalacji narzędzi programistycznych będzie ważył więcej.

Jeśli atakujący był do tej pory w stanie przeniknąć do systemu, aby mógł wywołać dowolne narzędzia znajdujące się na serwerze, oznacza to poważne naruszenie bezpieczeństwa. Bez narzędzi programistycznych istnieje wiele innych sposobów zapisywania danych binarnych do pliku, a następnie uruchomienia chmod na tym pliku. Osoba atakująca, która chce w tym momencie użyć niestandardowego pliku wykonywalnego kompilacji w systemie, może równie dobrze skompilować ją na własnym komputerze i przenieść na serwer.

Należy zwrócić uwagę na inne, bardziej odpowiednie rzeczy. Jeśli zainstalowane oprogramowanie zawiera błąd bezpieczeństwa, istnieje kilka sposobów na ujawnienie go atakującemu:

Pakiet może zawierać plik wykonywalny suid lub sgid.
Pakiet może uruchamiać usługi w systemie.
Pakiet może instalować skrypty, które są wywoływane automatycznie w określonych okolicznościach (dotyczy to zadań cron, ale skrypty mogą być wywoływane przez inne zdarzenia, na przykład gdy zmienia się stan interfejsu sieciowego lub gdy użytkownik się loguje).
Pakiet może instalować i-węzły urządzeń.

Nie spodziewałbym się, że narzędzia programistyczne będą pasować do jednego z powyższych i jako taki nie jest pakietem wysokiego ryzyka.

Jeśli masz przepływy pracy, w których korzystasz z narzędzi programistycznych, musisz najpierw zdecydować, czy są to uzasadnione przepływy pracy, a jeśli tak, to zainstaluj narzędzia programistyczne.

Jeśli okaże się, że tak naprawdę nie potrzebujesz tych narzędzi na serwerze, powinieneś powstrzymać się od ich instalowania z wielu powodów:

Oszczędza miejsce na dysku, zarówno na serwerze, jak i na kopiach zapasowych.
Mniej zainstalowane oprogramowanie ułatwia śledzenie zależności.
Jeśli pakiet nie jest potrzebny, nie ma sensu podejmować dodatkowego ryzyka związanego z jego instalacją, nawet jeśli ryzyko to jest niewielkie.

Jeśli zdecydujesz, że ze względów bezpieczeństwa nie zezwolisz nieuprzywilejowanym użytkownikom na umieszczanie własnych plików wykonywalnych na serwerze, to powinieneś unikać nie narzędzi programistycznych, ale raczej katalogów zapisywalnych dla tych użytkowników w systemach plików zamontowanych z uprawnieniami do wykonywania. Narzędzia programistyczne mogą być nadal przydatne, nawet w takich okolicznościach, ale nie jest to bardzo prawdopodobne.

— kasperd
źródło

6

Dodam do tego, że wiele systemów produkcyjnych opiera się na zinterpretowanym kodzie (np. PHP, Perl, Python, ...). Zakaz używania narzędzi programistycznych w tym kontekście nie miałby sensu. Uważam, że kompilatory gccnie chcą przedstawiać wyższego ryzyka niż te. Jak mówisz, osoba atakująca, która jest w stanie korzystać z kompilatorów zainstalowanych w systemie, zazwyczaj jest w stanie robić gorsze rzeczy, na przykład przesyłając własny (prawdopodobnie statycznie powiązany) plik wykonywalny.

— Bruno

3

Odpowiedni: Mała wersja wget (51 bajtów?) . Przykład z życia osoby atakującej przenoszącej plik binarny na serwer przy użyciu kolejnych echoinstrukcji do pliku. Cały proces jest zautomatyzowany za pomocą skryptu znajdującego się w tym samym łączu.

— Adi

2

@Adnan, ciekawe. O ile mogę stwierdzić, główną wadą bezpieczeństwa w tym przykładzie DVR jest fakt, że atakujący może telnet do niego jako root z hasłem 123456. Posiadanie lub brak posiadania wgeta lub innych narzędzi (przed atakiem) nie ma wtedy większego znaczenia.

— Bruno

15

makejest powłoką, która ma inną składnię niż bash.

Kompilator podobny gccdo potężnego jest awkskonfigurowany z zestawem podstawień, których standard awknie obsługuje. Jest niezgodny z POSIX sortlub catwprowadza śmieci do wyjścia. Jest to interaktywny edytor tekstowy (pomyśl vi), który jest skonfigurowany do edycji po uruchomieniu, a następnie wyjścia przed wyświetleniem interfejsu użytkownika.

Nie ma w nich nic z natury niepewnego, nie powodują, że twoja maszyna jest bardziej niepewna niż ta, w której masz catprzekierowanie powłoki bash + +.

— ignis
źródło

2

Odpowiedź, więc zen, nie wiem jak ją ocenić.

— kasperd

4

@kasperd Ta odpowiedź jest poważna. Pomyślałem, że przybliżenie punktu widzenia programisty może być pomocne. Funkcja, która tłumaczy dane wejściowe na dane wyjściowe, nie wprowadza luki w zabezpieczeniach tylko dlatego, że dane wyjściowe są w formacie zrozumiałym dla procesora.

— ignis

1

Zgadzam się z twoją opinią. Myślę, że twoja odpowiedź jest świetną lekturą dla każdego, kto już się z nią zgadza. Martwię się tylko, że twoja odpowiedź może być żartem dla kogoś, kto się z tym nie zgadza.

— kasperd

Ta odpowiedź podoba mi się bardziej niż przyjęta :)

— Ruslan

15

makesamo w sobie jest w porządku. makejest jedynie strukturą śledzenia i automatyzacji zależności. Jest jednak zwykle używany w połączeniu z kompilatorami, a te najlepiej nie powinny być dostępne w systemie produkcyjnym, ponieważ są całkowicie niepotrzebne. To samo dotyczy wszystkich niepotrzebnych pakietów, niezależnie od tego, czy są to biblioteki współużytkowane, tłumacze itp. Oprogramowanie zainstalowane w systemach produkcyjnych powinno być ściśle kontrolowane i powinny być obecne tylko te pakiety, które są wymagane przez aplikację.

Powinieneś budować aplikację na serwerze kompilacji, pakować ją, a następnie wdrażać pakiet binarny w systemach produkcyjnych.

Uwaga: natywne narzędzia do pakowania są do kitu . Nawet nie zawracaj sobie głowy próbowaniem ich zetrzeć. Zamiast tego sprawdź Jordan Sissel's fpm. Sprawia, że pakowanie jest absolutną radością.

— EEAA
źródło

8

Pytam z ciekawości i niewiedzy: dlaczego mówisz, że obecność kompilatorów jest „znaczącym problemem bezpieczeństwa?” Jaki jest problem bezpieczeństwa z zainstalowanym kompilatorem? Czy to po prostu kwestia tego, czy nie powinieneś budować kodu na serwerze produkcyjnym, a zatem kompilator jest zbyteczny, czy też rzeczywiście istnieje poważny problem z bezpieczeństwem związany z obecnością samego kompilatora?

— reirab

11

Chociaż budowanie aplikacji na oddzielnym serwerze jest dobrym pomysłem, stwierdzenie, że obecność kompilatorów w systemie produkcyjnym jest znaczącym problemem bezpieczeństwa, nie ma sensu. Co z językami skryptowymi i systemami skompilowanymi w JIT (Perl, Python, Java, ...)?

— Bruno

3

Obecność kompilatorów w środowisku produkcyjnym nie stanowi „znaczącego zagrożenia bezpieczeństwa”. Ja sam przeniosłem pliki binarne do zainfekowanych urządzeń za pomocą echoi base64. W rzeczywistości możesz to zrobić za pomocą szeregu echoinstrukcji i żadnego innego narzędzia .

— Adi

1

Wszystkie dobre punkty. Zredagowałem swoją odpowiedź, aby wyjaśnić.

— EEAA

9

Przeciwnie, potencjalnym problemem nie jest posiadanie makena serwerze produkcyjnym, potencjalnym problemem jest budowanie aplikacji na serwerze produkcyjnym zamiast wdrażania przetestowanych, wcześniej zbudowanych obrazów. Być może istnieją uzasadnione powody tej metodologii, ale jest to jedna z nich, z którą zdecydowanie się sprzeczałbym, gdyby ją poproszono.

— Jan
źródło

4

Pytasz, czy makepowinien zostać zainstalowany na serwerze produkcyjnym, ale moje prawdziwe pytanie brzmiałoby: kto ma dostęp do tego serwera produkcyjnego i jakie masz zabezpieczenia, aby poradzić sobie z wtargnięciem? Jeśli makenie został zainstalowany, ale ktoś uzyskał rootdostęp, zgadnij co? Mogą ręcznie zainstalować makei cokolwiek chcą.

Surowa rzeczywistość związana z bezpieczeństwem komputera polega na tym, że chcesz zapobiec niechcianemu dostępowi, obsesja na punkcie blokowania dostępu nie jest tak ważna, jak:

Kto ma dostęp do serwera?
Co możesz zrobić, aby cofnąć się po następstwie włamania?

Wszystko zależy od rodzaju wykonywanej pracy. Pracuję przede wszystkim w świecie serwerów WWW, a moje podejście jest zasadniczo takie, że każdy, kto otrzymuje ode mnie dostęp do serwera produkcyjnego, musi udowodnić swoje umiejętności, wiedzę i dojrzałość. Otóż to. Czasami zajmuje to kilka dni. Czasami zajmuje to miesiące. Ale w zasadzie najlepszą linią bezpieczeństwa na serwerach produkcyjnych jest kontrolowanie dostępu do wielu innych rzeczy, które robimy, aby wzmocnić serwery.

— JakeGould
źródło

1

makesam w sobie jest nieszkodliwy. Wszystko, co robi, to uruchamianie aplikacji w ustalonej kolejności, w zależności od określonych zależności i plików już istniejących w systemie. Może być nawet przydatny jako część procesu instalacji: możesz go użyć do umieszczenia gotowych plików tam, gdzie są potrzebne, do uruchomienia testów jednostkowych lub innych rzeczy.

Musisz jednak rozważyć, do czego dokładnie chcesz go użyć. Jest często używany w połączeniu z kompilatorami i innymi narzędziami do budowania aplikacji, a te mogą być użyte do zanegowania niektórych linii obrony. Ale makenie można tego robić, jeśli narzędzia nie są dostępne.

— The Spooniest
źródło