NFsec Logo

Chroniąc SSH przed zbieraniem adresów z known_hosts

25/05/2019 w Administracja, Bezpieczeństwo Możliwość komentowania Chroniąc SSH przed zbieraniem adresów z known_hosts została wyłączona

J

eśli używasz SSH to Twój klient przechowuje w katalogu domowym listę mapującą nazwy hostów i adresy IP każdego zdalnego hosta, z którym się połączyłeś. Ta „baza danych”, znana jako plik known_hosts może zostać wykorzystana przez atakujących, którzy naruszyli konta użytkowników. Rezultatem odczytania tego pliku jest „obraz” sieci, ujawniający, do których systemów mamy jeszcze połączenie. Może ułatwić to szkodliwemu oprogramowaniu i innym szkodliwym skryptom w rozprzestrzenianiu się na inne systemy, gdy tylko jeden system w sieci został skompromitowany. Plik ten jest dostępny w katalogu ~/.ssh każdego użytkownika, który chociaż raz łączył się jako klient SSH z zdalnym systemem. Jest on na tyle użyteczny, że w przypadku zmiany podpisu serwera – klient SSH będzie chronić użytkownika, powiadamiając go o tej sytuacji komunikatem typu:
[ czytaj całość… ]

Trochę o ulimit oraz prlimit

19/04/2019 w Administracja Możliwość komentowania Trochę o ulimit oraz prlimit została wyłączona

W

systemach operacyjnych każdy proces ma określony zestaw zasobów dostępnych w czasie jego życia. W przypadku Linuksa obejmują one takie rzeczy jak: ilość otwartych plików, rozmiar pliku z zrzutem pamięci, liczbę wątków, czy rozmiar stosu. Każdy zasób ma dwie granice: miękką (ang. soft) oraz twardą (ang. hard). Wartość graniczna zasobów może wahać się pomiędzy [miękką, a twardą] granicą. Pierwszą można uznać za wartość domyślną, a drugą za wartość maksymalnego pułapu. Zadaniem jądra jest upewnienie się, że te ograniczenia są egzekwowane.
[ czytaj całość… ]

Brezent na SSH

25/03/2019 w Administracja, Bezpieczeństwo Możliwość komentowania Brezent na SSH została wyłączona

B

rezent (ang. tarpit), czyli płachta na usługę. Jest usługą sieciową, która celowo wprowadza opóźnienia w obsługiwanym protokole spowalniając w ten sposób klientów i zmuszając ich do oczekiwania przez określony czas. Zachowanie to spowalnia lub zatrzymuje sondowanie i atakowanie systemów / usług. Skanery, skrypty i inne narzędzia atakującego są związywane z konkretną usługą / portem i nie mają możliwości ruszyć dalej (zazwyczaj działają synchronicznie wykonując pracę host po hoście / port po porcie). Nakłada to na atakującego większy koszt pod względem czasu i zasobów niż ponosi go obrońca.
[ czytaj całość… ]

Postfix – wyciek UID użytkownika i wewnętrznej adresacji sieciowej

13/02/2019 w Administracja, Bezpieczeństwo Możliwość komentowania Postfix – wyciek UID użytkownika i wewnętrznej adresacji sieciowej została wyłączona

P

ocztę e-mail kiedyś wysyłało się i odbierało w terminalu. Do dzisiaj czasami korzystam z takich programów jak mutt, czy alpine. Cała taka korespondencja jest wysyłana i odbierane przez serwer SMTP (ang. Simple Mail Transfer Protocol) Postfix. Problem w tym, że w standardowej konfiguracji odbiorca naszych wiadomości będzie w stanie zobaczyć ID naszego użytkownika w systemie:

Received: from stardust.nfsec.pl (unknown [17.197.105.219])
  by firewall.hes.trendmicro.eu (TrendMicro Hosted Email Security) with ESMTPS id 22E82
  for <abuse_the@int3rn3t.pl>; Sun, 10 Feb 2019 11:47:27 +0000 (UTC)
Received: by stardust.nfsec.pl (StarDustMX, from userid 666)
  id DD41460069; Sun, 10 Feb 2019 12:47:26 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
  by stardust.nfsec.pl (StarDustMX) with ESMTP id D60FD60068
  for <abuse_the@int3rn3t.pl>; Sun, 10 Feb 2019 12:47:26 +0100 (CET)

To samo tyczy się adresów IP komputerów w sieci wewnętrznej LAN, które mogą korzystać z takiego centralnego serwera pocztowego, czy też przypadku ukrywania się za CloudFlare, kiedy to musi zostać stworzony oddzielny serwer e-mail, aby oryginalny adres IP serwera web pozostał w ukryciu.
[ czytaj całość… ]

Rozmowy przy Kafce #1

19/11/2018 w Administracja Możliwość komentowania Rozmowy przy Kafce #1 została wyłączona

J

eśli chcemy odbyć krótką rozmowę o wydajności producenta kafki (w kontekście: logstash → kafka ← logstash → elasticsearch) musimy porozmawiać o dwóch rzeczach. Po pierwsze: opóźnieniu – ile czasu upłynęło od czasu wywołania metody send(), dopóki komunikat nie pojawi się na brokerze. Po drugie: przepustowości – ile wiadomości może wysłać producent do brokera na sekundę. Dlaczego musimy obawiać się o te dwie wartości? Jeśli procesowanie wiadomości zajmuje nam 10 milisekund (opóźnienie) to wyraźnie przepustowość jest ograniczona do 100 wiadomości na sekundę. Patrząc na to w ten sposób można dojść do wniosku, że im wyższe opóźnienie tym większa przepustowość. Jednak związek między opóźnieniem, a przepustowością nie jest tak trywialny.
[ czytaj całość… ]

Krótka historia poleceń „rm” oraz „rmdir”

15/07/2018 w Administracja Możliwość komentowania Krótka historia poleceń „rm” oraz „rmdir” została wyłączona

W

przeciwieństwie do wielu podstawowych narzędzi systemów Unix i Linux, nazwa polecenia rm nie jest starsza niż sam Unix. W poprzednikach Uniksa – Compatible Time Sharing System (CTSS) i Multics, polecenie używane do usuwania plików nazywało się delete (w Multics opcjonalnie mogło zostać skrócone do dl). W systemie Unix nazwa rm została prawdopodobnie użyta, aby odzwierciedlić filozofię zmiany z usuwania plików na usuwanie wpisów, które prowadziły do ich pozycji.
[ czytaj całość… ]

Nasłuch na wszystkich adresach IP i wszystkich portach

29/06/2018 w Administracja Możliwość komentowania Nasłuch na wszystkich adresach IP i wszystkich portach została wyłączona

A

ny-IP w Linuksie to możliwość odbierania pakietów i nawiązywania połączeń przychodzących na adresy IP, które nie są jeszcze skonfigurowane na hoście. Umożliwia to skonfigurowanie serwera, aby odpowiadał w określonym zakresie adresacji sieciowej jakby była ona lokalną – bez konieczności konfigurowania adresów na interfejsie. Dla przykładu: chcemy, aby nasza maszyna odpowiadała dla całej adresacji 192.168.0.0/24 bez konieczności konfiguracji każdego adresu IP na interfejsie/sach.
[ czytaj całość… ]

Podstawy systemów rozproszonych: odległości węzłów

14/05/2018 w Administracja, Debug Możliwość komentowania Podstawy systemów rozproszonych: odległości węzłów została wyłączona

W

edług „Wprowadzenia do systemów rozproszonych” charakterystyczne opóźnienie pomiędzy węzłami ( serwerami / agentami / procesami / aktorami ) wynika z: operacji wewnątrz samych węzłów, które są „szybkie„; operacji pomiędzy węzłami, które są „wolne” – co jest szybkie, a co wolne zależne jest od tego, co wykonuje sam system. Za przykład posłuży nam klaster, który komplet danych utrzymuje po części na każdym węźle wchodzącym w jego skład. Czyli klient odpytując klaster o część interesujących go danych może odpytać o nie dowolny węzeł, ale musi poczekać aż jego odpowiedź zostanie złożona z danych zwróconych przez każdego uczestnika w klastrze. Tak na przykład działa shardowanie danych w Elasticsearch.
[ czytaj całość… ]

IP-Radar

28/04/2018 w Administracja Możliwość komentowania IP-Radar została wyłączona

J

eśli jesteś administratorem sieci i klient zgłasza Ci pewne problemy z łącznością do drugiej sieci. Aby odkryć przyczynę problemu musisz znać konkretny adres IP punktu odniesienia w docelowej sieci. Każdy prawdopodobnie ma własną metodę podejścia do tego problemu. Zazwyczaj trzeba przejść przez podsieci, wyszukać adresy IP, a następnie zweryfikować możliwe straty pakietów do nich. Firma CDN77 stworzyła unikalną bazę adresów IP, które odpowiadają na ping w internecie. W celu znalezienia żądanego adresu IP dowolnej podsieci wystarczy wpisać jej adres lub numer ASN (ang. Autonomous System Number). Otrzymamy wówczas następujące informacje: listę podsieci, adresy IP odpowiadające na ping oraz czasy opóźnienia RTT (ang. Round-Trip Delay Time). Dzięki temu możemy zaoszczędzić trochę czasu na identyfikacji tego typu problemów.

Więcej informacji: IP-Radar

Top 10 darmowych i publicznych serwerów DNS

02/04/2018 w Administracja Możliwość komentowania Top 10 darmowych i publicznych serwerów DNS została wyłączona

Poniżej znajduje się aktualizacja wcześniejszej listy:

1. CloudFlare:
1.1.1.1
2. Quad9:
9.9.9.9
3. Google:
8.8.8.8, 8.8.4.4
4. CleanBrowsing:
185.228.168.168, 185.228.168.169
5. OpenDNS:
208.67.220.220, 208.67.222.222
6. Norton ConnectSafe:
199.85.126.10, 199.85.127.10
7. Comodo Secure DNS:
8.26.56.26, 8.20.247.20
8. DNS.Watch:
84.200.69.80, 84.200.70.40
9. VeriSign Public DNS:
64.4.64.6, 64.6.65.6
10. Yandex DNS:
77.88.8.88, 77.88.8.2

Więcej informacji: DNS Resolvers Performance compared, Jak znaleźć najszybszy publiczny serwer DNS w Polsce?