vermin.eu.org

SBS lubi być sam. Sam możnowładnie pełnić rolę pana i władcy. Nie lubi, kiedy cokolwiek mu przeszkadza. Ba, wyjątkowo źle reaguje jak coś mu przeszkadza, zazwyczaj to wyłączając. Niestety nie odłącza zewnętrznego urządzenia (może Centro/MBE dzięki NAP będzie to potrafić?), a wyłącza swoje funkcjanolności, w skrajnej sytuacji wyłączając sam siebie. Jak się okazuje, można zabronić mu wyłączania serwera DHCP w momencie gdy wróg pojawi się w naszej sieci (albo testowo włączymy routerek, odpalimy serwerek linuksowy nie rekonfigurując portów VMa czy cokolwiek innego). Okazuje się, że można przestrzec się przed tak trywialnym problemem w wyniku którego nagle przestaje działać nam sieć. Wystarczy uruchomić edytor rejestru, przejść od klucza HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Dhcpserver\Parameters a następnie dodać w nim wartość typu DWORD o nazwie DisableRogueDetection i wartości 1. Restart serwera (hahaha) i voila - działa.
Oczywistym minusem tego rozwiązania jest fakt, że jak wyłączymy wyłączanie serwisu DHCP w sieci, to otwieramy się na swoisty wektor ataku, polegający na tym, że wstawia się wrogi serwer dhcp do sieci, on ustawie siebie jako proxy i przechwytuje ruch do sieci. Niemniej oczywiście mamy wdrożonego IPSec’a i nie musimy obawiać się takich prozaicznych ataków. Prawda?

Dziennik Internautów zamieścił artykuł, że istotnym wzrostem bezpieczeństwa zapobiegającym phishingowi byłoby stworzenie specjalnych domen .safe oraz .bank.

Pytanie, czy nazwa domeny coś znaczy? Czy nadal domeny .com to tylko rzeczy komercyjne, czy .org to tylko organizacje, czemu nie powstały domeny XXX? Pytanie jest czysto retoryczne. Teoretycznie domenę .us powinny posiadać jedynie podmioty fizycznie znajdujące się na rynku amerykańskim (chyba nawet dość fizycznie) a tak naprawdę nie ma z tym większego problemu. Jeśli wprowadzimy koncesjonowanie tych domen (np. tylko dla zarejestrowanych podmiotów) to wprowadzimy dużo większe problemy - brak konkurencji.

Po pierwsze trzeba by określić międzynarodowe standardy czym taka instytucja jest i jakimi dokumentami powinna się charakteryzować. Nawet jeśli to zrobimy… to ja i tak nie wierzyłbym papierom pochodzącym chociażby z Nigerii…
Po drugie - zdobycie pożądanych dokumentów rodzi problemy natury finansowej - one zazwyczaj nie mało kosztują. Jeśli tego nie zrobimy a użytkownicy zostaną wyedukowani to przecież nikt nie będzie korzystał z usług sklepów który się nie zautoryzuje w safe, co zdecydowanie podniesie koszty obsługi (monopolizacja rynku).
Po trzecie załóżmy, że jakieś podmioty w jakimś kraju nazywają się podobnie - to kto powinien mieć domenę safe? Jeśli powiemy, że to zależy od kraju, to po co wprowadzać domeny TLD .safe a nie safe.<ISO_County_Code>?
I te trzy punkty chyba nie wyczerpują do końca tematu…

Po czwarte (dla mnie najciekawsze) - otwieramy nowy wektor ataku, który może spowodować paraliż internetu. Już teraz nie aż tak rzadkie są problemy z serwerami DNS, które wydają się najsłabszym elementem internetowej układanki. Jeśli wprowadzilibyśmy prawie automatyczne ufanie nazwie domeny, to ataki na różnego rodzaju lokalne resolvery, serwery odpowiedzialne za obsługę domen, DNS poisoning etc. wzrosną niepomiernie. A przecież wystarczy zrobić dobrego DDOSa na najpopularniejsze NSy, żeby połowa ludzi miała poważne problemy z dostępem do internetu (NSy głównych operatorów telekomunikacyjnych, TLD, główne bazy krajowe).

To wcale nie wydaje się takie niewykonalne - na razie po prostu jest to nieopłacalne (bo można taniej osiągnąć odpowiedni poziom phishingu), ale jak uczy nas ekonomia, jeśli zasoby stają się ograniczone, to wzrasta akceptowalny poziom kosztów, które dla osiągnięcia rezultatu gotowi jesteśmy ponieść. A że przypadkowymi ofiarami może być całkiem spore grono użytkowników Internetu? Cóż - collateral damage…

Uff, mojej kochanej księgowości udało się w końcu przejść ścieżkę zgodną z normą ISO i opłacić fakturę o zawrotnej wielkości 100 pln. Oczywiście skoro zrobili to tak ‘wcześnie’ to część sesji okazała się już zapchana (pomimo w miarę niskiego numeru rezerwacji).
No cóż - następnym razem to po prostu opłacę sobie to samemu i wezmę urlop albo zgłoszę się po delegację twierdząc, że udział jest bezpłatny…

Nic to - udało mi się skompletować jakiś harmonogram. Zapiszę go sobie tutaj, będę miał dowód, że wszystko się zgadza i jestem na tych sesjach na które się rejestrowałem, (bo raz już się zdarzyło, że nastąpiło jakieś niezaplanowane przesunięcie w harmonogramie).

Ten wpis rozszerzę w miarę postępu sesji i opiszę czy warto było na nią pójść (oczywiście będzie to całkowicie subiektywna ocena).

25.04.2007

• 09:30 - 11:00
  Jak w praktyce zarządzać zintegrowaną aktualizacją oprogramowania oraz BIOS. Przykład platformy Dell.
  Eksprt dziedzinowy (Dell)

• 11:25 - 12:55
  Zabezpieczenie nieprzerwanej dostępność danych z wykorzystaniem rozwiązań storage Hewlett-Packard opartych o system Windows Server
  Eksprt dziedzinowy (Hewlett-Packard)

• 14:00 - 15:30
  Bezpieczeństwo aplikacji opartych o SQL Server w praktyce
  Artur Żarski, Tomasz Kopacz (Microsoft)

• 15:45 - 17:15
  Wykorzystanie Microsoft Operations Manager 2007 w usługach HostedWindows.pl i HostedExchange.pl
  Ziemowit Borowski, Michał Szafrański  (DCS Computer Consultants Group Sp. z o.o.)

26.04.2007

• 09:00 - 10:30
  Nowa generacja usług katalogowych Active Directory. Zarządzanie AD w środowisku wieloodziałowym oraz nowe usługi sieciowe.
  Ekspert dziedzinowy

• 10:55 - 12:25
  Windows PowerShell od podstaw. Wprowadzenie do zasad tworzenia skryptów
  Marcin Pytlik (Bowei Partners)

• 13:25 - 14:55
  Microsoft Windows PowerShell. Praktyczne zastosowanie narzędzia do zarządzania systemami Microsoft
  Marcin Pytlik (Bowei Partners)

• 15:20 - 16:50
  Sesja Plenarna

Drugi rok z rzędu odbędzie się konferencja odnośnie bezpieczeństwa w sieciach Microsoft. Zaskoczył mnie co prawda tytuł tejże - zacząłem się zastanawiać dlaczego DevDays zamiast być połączone z konferencją dla specjalistów IT (jak dotychczas), są połączone z MSS. Niemniej przejrzenie agendy rozjaśniło mi sprawę - także dla programistów jest to konferencja poświęcona bezpieczeństwu.
Cóż - zobaczymy jak będzie, bo ja pojawię się na pewno. Sezon konferencji i seminariów czas rozpocząć

Łącząc się z hostem poprzez SSH z nowego komputera, jesteśmy pytani o to, czy jesteśmy pewni z kim się łączymy. To pytanie, to raptem odcisk klucza publicznego serwera, który musimy zweryfikować.

Osobiście zawsze “zarządzałem” kluczami poprzez stronę WWW na której publikowałem odciski kluczy. Niemniej artykuł na Debian Administration, a dokładnie komentarze do niego pokazały mi ciekawą drogę.

Jak podaje RFC 4255, wystarczy dodać pewien typ rekordu do opisu strefy oraz uruchomić ssh z odpowiednią opcją aby łatwo zweryfikować drugą stronę połączenia. Do szukanej domeny (np. example.com) wystarczy dodać rekord SSHFP zawierający klucz (szczegółowa definicja).
Wygląda to mniej więcej następująco (RSA potem DSA):

Te linijki można wygenerować za pomocą komend:
ssh-keygen -r example.com -f /etc/ssh/ssh_host_rsa_key
ssh-keygen -r example.com -f /etc/ssh/ssh_host_dsa_key
lub dla starszej wersji bind
ssh-keygen -r example.com -f /etc/ssh/ssh_host_rsa_key -g
ssh-keygen -r example.com -f /etc/ssh/ssh_host_dsa_key -g

Żeby się połączyć wystarczy wydać komendę ssh example.com -o “VerifyHostKeyDNS=yes” (putty na razie nie ma opcji pozwalającej na weryfikację klucza zapytaniami DNS).

Chociaż jest to mało prawdopodobne, to oczywiście warto pamiętać, że jeśli ktoś zmanipuluje rekordy strefy (szczególnie, jeśli ułatwiamy sobie sprawę i trzymamy wszystkie informacje jako klucze swojej pod domeny, np. serwerX.moja_domena.com) to jesteśmy niestety mocno wystawieni na atak typu man-in-the-middle, więc warto przemyśleć swoją strategię postępowania (dodatkowa autoryzacja poprzez klucze dostępu, wpisy SSHFP per host per domain, weryfikacja rekordów od czasu do czasu).

Skoro wspomnieliśmy już ogólnie o tym cóż to to monitorowanie jest, warto by wszystko skonfigurować, żeby móc cieszyć nasze oczy pięknymi grafami/tabelkami/wykresami czy też jakąkolwiek inną reprezentacją zbieranych danych.

1. Instalacja
Przede wszystkim musimy zainstalować oprogramowanie agentów. W wypadku systemów Windows ścieżka jest prosta:
Panel Sterowania -> Dodaj lub usuń programy -> Składniki systemu Windows -> Narzędzia zarządzania i monitorowania. Po chwili mamy już zainstalowanego agenta.
W Debianie sytuacja jest także prosta. Wystarczy zainstalować paczkę snmpd (aptitude install snmpd). Dodatkowo przydadzą się nam narzędzia z paczki snmp (aptitude install snmp).
Pod Windows, jeśli nie chce nam się szukać, ściągąc i kompilować net-snmp tools z którego to pakietu pochodzi wykorzystywane w dalszej części narzędzie snmpwalk, warto ściągnąć Windows Management Instrumentation (WMI) SNMP Provider, który pozwoli na odpytywanie SNMP z poziomu WMI.

2. Weryfikacja
W systemie Windows zweryfikujemy działanie SNMP poprzez uruchomienie MMC Usługi (services.msc) i sprawdzenie czy działa serwis Usługa SNMP oraz (ewentualnie) Usługa SNMP Trap. Jest to też ciekawostka, ponieważ jest to jedyna (znana mi) usługa, która całą swoją konfigurację ma właśnie w tym miejscu. Wydawałoby się, że warto jej poświęcić chociaż małe MMC, a tu nic.
W systemie Debian wystarczy oczywiście wydać komendę ps `cat /var/run/snmpd.pid`, dzięki której zobaczymy, czy demon SNMP działa. Daemon tu jest agentem a nie serwerem, o czym warto pamiętać.

OK, może i SNMP działa, ale czy coś do nas powie? Czy odpowie na na nasze wołania? Wystarczy wydanie komendy snmpwalk -v 1 -c public localhost żeby ekran (jeśli wszystko jest ok) pokrył się tonami kodu, wyglądającego mniej więcej tak:

Te kody swoją droga coś znaczą - pierwsza pozycja to tzw. MIB, czyli nie “faceci w czerni”, ale nazwa danej (tu w postaci numerycznej), np. naszego czujnika temperatury albo pokrętła. Część po znaku równości to jak łatwo się domyśleć, aktualna wartość tegoż MIBa. MIBy można podawać za pomocą cyfrowego łańcucha znaków… albo, jeśli mamy coś co to ładnie przetłumaczy (czyli zbiory tekstowe z opisem MIBów), możemy zapytać się ładniej - snmpwalk -v 1 -M. -c public localhost IP-MIB::ipAdEntIfIndex co poda nam indeksy interfejsów w systemie.
Sama komenda ma strukturę snmpwalk -v wersja_protokołu -M katalog_z_MIBami -c community_name hostname MIB.

3. Konfiguracja
Domyślnie SNMP działa na lokalnym serwerze (localhost) z communityname public dla odczytu i private dla odczytu/zapisu (tak, za pomocą SNMP można także sterować urządzeniem!). Windows ma tylko community public i przyjmuje połączenia od dowolnego hosta. Warto zmienić ciut te wartości oraz podać, gdzie nasz sprzęt się znajduje (jeśli trochę go mamy). Odpowiednie wartości wpiszemy we właściwościach usługi (services.msc -> usługa SNMP -> własciwości: zakładka Agent i Zabezpieczenia) lub w /etc/snmp/snmpd.conf.
Tutaj także możemy zmodyfikować jakiego rodzaju informacje agent SNMP będzie monitorować (sieć, procesor, dyski, etc.) Gama możliwości jest naprawdę duża.

W systemie Windows możemy poza standardowymi parametrami odpytać następujące serwisy:

• WINS
• DHCP
• IIS
• LAN Manager
• RRAS (Routing and remote access)
• IAS
• liczniki System Monitora (wszystkie liczniki wydajności TCP/IP i usług na nim opartych)

Z czego sterować można IAS, Lan Managerem i WINSem.

4. Zarządca
Było zarządców wielu, ale żaden z nich nie śmiał zagrać przy… Cóż, ciężko powiedzieć. W zasadzie to HP OpenView narzuca się samo, niemniej my mamy mniejsze potrzeby. Chcemy monitorować. Chcemy żeby było prosto, łatwo i darmo. Chcemy MRTG (tak, wiem jest też Cacti - ale ono jest za bardzo rozbudowane na początek).
MTRG można zainstalować pod Windows oraz pod Linuxem. Program odpytuje agenta (agentów) w zadanych interwałach czasu (cron/at), zbiera dane i przetwarza je na postać graficzno -tekstową (HTML + obrazki PNG). Konfiguracja wygląda tak samo pod obydwoma systemami. Należy podać mu skąd ma pobrać dane, jakie MIBy nas interesują, podać parametry interfejsu, czyli tak naprawdę wytyczne odnośnie rysowania obrazka i już.
Na dodatek MRTG ma przyjemne “wizardy” tworzące samoczynnie konfigurację:

tworzy podstawowy plik konfiguracyjny dla społeczności public na localhost informując że dane będą w katalogu WorkDir

stworzy dla nas odpowiednie pliki
Teraz tylko parokrotne uruchomienie mrtg (mrtg /etc/mrtg/MartaG.cfg) tworzące resztę wymaganych plików uwieńczy naszą pracę sukcesem. Podstawowa konfiguracja zakończona i możemy popatrzeć jak to wszystko wygląda.

Należy pamiętać, że aby odczytać te dane na stacji administratorskiej to albo skonfigurujemy poprawnie IISa pod Windows lub Apache pod Linuxem, albo postawimy jakiś mały dedykowany serwer, jak np. microhttp, który idealnie sprawdzi nam się do rzadkiego publikowania statycznych informacji (chyba, że planujemy inne obciążenie tegoż serwisu - ale po co?).

Do czego właściwie potrzebne to wszystko? Żeby móc stworzyć własny, rozproszony SMS dla ubogich. Jakby nie można było kupić licencji… No, ale ten system daje także rzeczy, których wprost z SMSa wyciągnąć się nie da, a poznać je warto - jak chociażby lista aktualnych połączeń z danego komputera (stos TCP/IP), że nie wspomnę o podstawowym zadaniu MRTG, czyli monitorowaniu urządzeń sieciowych.

Dodatki: Narzędzia SNMP dla Windows.

Wyobraź sobie urządzenie, która ma ileś tam czujników - np. kaloryfer z termoregulacją. Masz odczyt temperatury (wartość1) i pokrętło (wartość2). Chcielibyśmy (jeśli kaloryfer to umożliwia) pobierać i monitorować urządzeniem zewnętrznym wartość tej temperatury (wartość1), a także ustawienie pokrętła (wartość2). Jak to zrobić (w dziedzinie komputerów)?

Monitorowanie sprzętu jest ważne - na przykład dlatego, że pozwala wykryć sytuacje prowadzące do nieodpowiednich zachowań. Zaczynając od tak banalnych rzeczy jak wysycenie pewnych parametrów (np. mierzenie poziomu zajętości dysku, badanie obciążenia procesora, stronicowanie pamięci i inne wąskie gardła), do zagadnień bezpieczeństwa (tu dla odmiany monitorowania bramki internetowej, co pozwoli nam stwierdzić, czy ktoś przypadkiem nie wykorzystuje naszego łącza pomimo (braku) zabezpieczeń w czasie teoretycznego braku aktywności). Monitorować można na wiele różnych sposobów, niemniej warto zainteresować się jednym z nich, dostępnym zarówno w systemach Windows i Linux - a przede wszystkim w dużej ilości urządzeń zewnętrznych (w szczególności sieciowych).

Do monitorowania wykorzystuje się protokół SNMP. Ten prosty protokół jest szeroko rozpowszechniony i doczekał się już swojej trzeciej wersji. Niemniej ponieważ w użyciu są przede wszystkim wersje 1 i 2, skupimy się na nich - żeby to zaczęło działać.

Do podstawowego działania każde monitorowane urządzenie powinno mieć program (agenta), który będzie pobierał stan jakiegoś wewnętrznego rejestru (np. przepływność interfejsu sieciowego) a następnie, odpytany przez zarządcę, podawał mu te dane. Agent może być także ciut proaktywny i w wypadku zadziałania zdefiniowanego warunku wysyłać do zarządcy odpowiednią informację (zwaną trap/pułapką). Do poprawnego działania w środowisku sieciowym potrzebne będą porty TCP 161 (odpytywanie) i 162 (pułapki). Przyda się jeszcze tzw. community name, czyli nazwa o którą będziemy odpytywać nasze urządzenie.

Na boku: Widać tu wyraźnie, że skoro jedynym zabezpieczeniem jest znajomość community name musimy przedsięwziąć inne środki bezpieczeństwa… lub wdrożyć wersję 3 protokołu SNMP.

OK - tyle teorii wystarczy. Jak to wszystko zrobić nie dopłacając? O tym w następnym artykule.

Ledwo zdążyłem podnieść WP do 2.1.1 a tu okazuje się, że konieczne jest przejście o wersję wyżej, ponieważ, jak piszą w ogłoszeniu, nawaliło bezpieczeństwo i jakiś cracker podmienił pliki na zawierające exploita. nie dotyczy to wszystkich, jedynie tych, którzy ściągali nową wersję w przeciągu ostatnich czterech dni.

Co jest dobre w tej sytuacji? Cóż, podano informację o konieczności migracji, podano mniej więcej od kiedy występuje problem, podano informację jak sobie z tym poradzić. Wszystko pięknie i ładnie.

Co mi się nie podoba? Dwie rzeczy. Z informacji można wywnioskować gdzie powinno się szukać exploita (na pewno w theme.php oraz w feed.php z katalogu wp-includes), na pewno w przesyłaniu zmiennych zawierająch suffixy “ix” oraz “iz”. Trochę z tego można wywnioskować, ba, biorąc pod uwagę, że nowa wersja zmienia nazwy plików, które zostały zmodyfikowane wystarczy porównać instalację 2.1.1 oraz 2.1.2 i już mamy rzecz na taleczu. Skoro tyle zostało po dane, to czemu…

Jednocześnie update robi dwie rzeczy - wiadomo, że upgrade zajmuje trochę czasu. Wiadomo też, że przy szczególnej zmianie z 2.1.1 do 2.1.2 tylko niektóre z nich ulegną podmianie, niektóre trzebawypada skasować.

…nie można wprost podać tej informacji (jak już przy jednym sec releasie było) i wydać paczki z szybką łątką, tylko trzeba przechodzić przez dość długotrwały proces aktualizacji? Ciut to bez sensu i denerwujące. Nie wspominam już o full-disclosure bo i tak info o tej dziurze niedługo się pojawi i tak. Ale co tu narzekać - trzeba przejść aktualizację i tyle. Again.

Jeśli jest to główny system kontroli dostępu do wrażliwych elementów infratruktury… cóż, think again.

Na boku - w prezentacji słychać, że to pudełko wraz ze schematami ma być prezentowane na najbliższym Blackhat conference. Cóż, ktoś chyba zdjął to z agendy

Źródło: infosecsellout

Istnieje w sieci komputer o nazwie netbios “23″. Niby nic takiego, ale… próba połączenia się z nim jednego z komputerów poprzez otoczenie sieciowe generuje w logach IPSa dziwne zdarzenie: “martian destination 0.0.0.23 from 192.168.10.141″. Co ciekawe znajduje się także właściwy adres IP i komputer rozpoczynający połączenie w końcu się połączy… ale zastanawia mnie, czy nadanie jako nazwy komputera adresu IP w postaci DWORD a na tym właśnie adresie otworzenie udziału nie spowodowałoby de facto przekierowania zapytania pierwotnego na tą drugą (DWORD) maszynę?

Takie właśnie pytanie przyniosło tu kogoś przez Google. Ponieważ temat jest jednym z tych religijnych (chociaż chyba coraz mniej), to jednak są zarówno pewne plusy jak i minusy takich rozwiązań, na temat których w własną opinię postaram się przedstawić w kontekście kilku zmiennych. Jest to ponadto decyzja biznesowa, odbijające się na domowym/firmowym budżecie - koszt licencji sensownego firewall na stację kliencką Windows to wydatek minimum 100 pln.

Oczywiście należy rozumieć fakt, iż bycie “za routerem” nie zawsze musi oznaczać bycia “niewidocznym” w sieci Internet, co dokonuje się zazwyczaj przez zastosowania jakiegoś rodzaju translacji portów (maskarada/SNAT) i (opcjonalnie) “ściany ogniowej”. Jest to oczywiste na poziomie ISP lub też sieci firmowych, niemniej nawet w usługach abonenckich, np. w jednej z opcji internetDSL dostajemy większą pulę adresową niż standardowe /30 (można dostać 5 możliwych do przypisania urządzeniom końcowym adresów IP) przez co komputery za routerem mogą używać adresów publicznych.
W tej sytuacji pomimo, że firewall i router nie są pojęciami tożsamymi, my jednak zajmijmy się sytuacją, kiedy gateway de facto jest dla nas urządzeniem:

• dokonującym translacji adresów (zamieniającym ruch wychodzący/przychodzący na jeden przyznany adres publiczny na szereg adresów prywatnych z pul 192.168.x.y(/16) 172.16.x.y(/12) 10.x.y.z(/8))
• posiadającym firewall nieprzenoszący ruchu przychodzącego z sieci zewnętrznej do sieci wewnętrznej o ile nie jest on powiązany z sesja nawiązaną z wewnątrz sieci (czyli odrzucającym wszystko przychodzące z zewnątrz o co się wyraźnie nie pytaliśmy)

Skoro ustaliliśmy już model wyjściowy, czas odpowiedzieć sobie na pytanie postawione w tytule notatki - czy instalować tego firewalla czy też nie?

Środowisko domowe a firma
Sieć domowa zazwyczaj składa się z jednego lub więcej komputerów. Użytkownicy tych komputerów często działają na kontach posiadających zbyt szerokie uprawnienia (administrator/root) i są sobie samymi sterem i okrętem. Komputery nie udostępniają żadnych usług i nie ma potrzeby dostępu do nich z zewnątrz poza ściśle wylistowanymi i zazwyczaj określonymi wstępnie na routerze przypadkami (GG, eMule, BitTorrent, soulseek, etc.) - niemniej instalowane jest na nich wiele niesprawdzonego oprogramowania, któremu warto odcinać możliwość kontaktu ze światem. Nie każdy komputerowy ET powinien móc dzwonić do domu - szczególnie, jeśli podczas komunikacji prześle także nasze poufne dane. W takiej sytuacji dodatkowa opcja zabezpieczeń - w szczególności właśnie filtrowania połączeń wychodzących, czego nie zapewnia wbudowany w Windows firewall, jest szczególnie ważna.
W firmie zazwyczaj mamy sytuację bardziej złożoną - zarówno ze względu na większą kontrolę punktu styku sieci wewnętrznej i zewnętrznej, która wykraczać powinna poza kontrolę stanu połączenia, ale bardziej wkraczać w filtrowanie na poziomie aplikacji i specyfikę protokołów komunikacyjnych. Ponadto zazwyczaj użytkownicy nie mają uprawnień administratora, zaś ich stacje robocze powinny być otwarte na dostęp administracyjny właśnie - aby pewne operacje mogły zostać przeprowadzone (zdalny pulpit, przejęcie pulpitu, kontrola aplikacji, kontrola maszyny i usług, etc.) W tej sytuacji i tak otwieramy maszynę na dostęp z zewnątrz - chociażby z “zaufanej” podsieci adminstratorskiej (tak jakby nie istniała możliwość oszukania switchy (arp poisoning), fałszowania adresów IP i innych takich), więc stawianie zapory ogniowej na każdej stacji może nie być aż tak konieczne, jak zapewnienie bezpieczeństwa serwerom albo stacjom roboczym pełniącym ich rolę oraz odpowiedniemu filtrowaniu w punkcie styku.

Sieć mała a rozległa
Czy skala sieci ma znaczenie? Moim zdaniem ma, i to odwrotnie proporcjonalne. Im większa sieć, tym mniejsza potrzeba używania firewalli na stacjach klienckich, im sieć mniejsza, tym potrzeba większa. Twierdzenie to wydaje się być dosyć niedorzeczne, przecież enterprise, ta skala, ta konieczność kontroli… Właśnie dlatego wydaje mi się, że tam można, ale nie za bardzo trzeba. W sieci o dużej skali stacje robocze powinno się dać łatwo spacyfikować a wszelkie zagrożenia wykryć ponieważ:

• W sieci powinny działać systemy analizujące/blokujące ruch na podstawie typowego zachowania - większość klientów wewnętrznych nie potrzebuje łączyć się na portach innych niż 25, 80, 110, 443. Ba, w większości przypadków także taki ruch nie zawsze jest pożądany kiedy cel jest poza adresacją wewnętrzną firmy… albo właśnie w niej, ale na maszynach, które nie pełnią danej roli. W zasadzie im firma większa, tym większa sieć, tym większa potrzeba stawiania takich maszyn w pewnych węzłach sieci.
• Zazwyczaj, chociażby z konieczności zmniejszenia domeny broadcastowej, zmniejszenia skali zniszczeń po ataku robaka, wielości oddziałów, budowy VPNów, DMZów i innych skrótowych oznaczeń, tworzy się dodatkowe, wewnętrzne firewalle, separujące odpowiednie segmenty sieci i nie pozwalające na przenoszenie nieodpowiedniego ruchu na szerszą skalę.
• Dostęp do sieci powinien być autoryzowany, chociażby 802.1x - to także zazwyczaj dzieje się przy budowie sieci większych, bo to dodatkowe maszyny czy też switche obsługujące ta technologię
• Switche mogą mieć ustawione triggery odłączające maszynę przy zbyt dużej ilości generowanych pakietów.
• Systemy antywirusowe w kluczowych miejscach sieci, wysyłają alarmy w wypadku zagrożeń pochodzących z wewnątrz.
• Istnieje możliwość szybkiego wycięcia klienta sprawiającego problemy - już w miejscu jego podłączenia do sieci, (co także wymaga odpowiedniego sprzętu).
• Stacje robocze nie pełnią funkcji repozytoriów danych, (ba, czasem to nawet tylko terminale klienckie łączące się z systemem macierzystym), więc ich partykularne bezpieczeństwo jest mniej cenne niż bezpieczeństwo sieci jako całości.

Co prawda ostatni punkt nie jest w pełni prawdą - ponieważ każdy system jest tak trwały, jak jego najsłabsze ogniwo - niemniej, jesli nałożymy pewne obostrzenia sieci korporacyjnej (integralność sprzętu) możemy to uproszczenie zastosować.

Te wszystkie rzeczy trudniej jest realizować w mniejszych sieciach, w mniejszych firmach, gdzie każdy dodatkowy czy tez przestarzały komputer jest i tak zagospodarowywany chociażby na maszynę do pisania - a nie na system bezpieczeństwa. W końcu to sprzęt który miałby chodzić 24/7, zużywać energię - i co ważne dla domowego użytkownika, czyli sieci o mikro skali - generować hałas.
Ponadto składowanie danych odbywa się właśnie na tych węzłach sieci, które generują ruch, wymiana danych odbywa się w stylu komputer-do-komputera(1), więc tam szczególnie potrzebna jest ścisła kontrola i możliwie wczesne raportowanie wszelkich możliwych nadużyć - takich jak nagła chęć komunikacji zegara systemowego ze światem. Więc im mniej rzeczy z powyższej listy zastosowane jest w Twojej sieci, tym bardziej powinieneś pomyśleć o stosowaniu zapory ogniowej.

Wielość interfejsów oraz maszyny przenośne
Nowoczesna maszyna zaczyna zawierać coraz więcej interfejsów - sieci przewodowe, bezprzewodowe (takie jak WiFi/WiMAX czy bluetooth i jego PANy) czy też komórkowe. Wszystkie z nich pozwalają dostęp do naszej maszyny i zgromadzonych na niej danych - niektóre jest łatwiej kontrolować (sieć kablowa) inne trudniej. Jeśli nie potrafimy panować nad medium, którym przesyłane są dane - a kto potrafi zapanować nad powietrzem i przenoszonymi przez nie falami EM - to powinniśmy pilnować mocno punktu końcowego.
Tu w szczególności ma zastosowanie konieczność posiadania zapory ogniowej za routerem. Przecież nagle nasza sieć wewnętrzna staje się otwarta - i wzmiankowany na wstępie router i jego firewall nie zapobiegają już atakom na nasza maszynę. Te ataki przychodzą z wewnątrz sieci! Stąd brak posiadania firewall oznacza możliwość wykorzystania naszej maszyny do celów nie do końca pożądanych. Ponadto wykorzystując sieci, które nas ‘chronią’ przed dostępem z zewnątrz same nadając nam wewnętrzną, nie przechodząca do internetu adresację, takie jak np. blueconnect, iPlus czy dowolny hotspot, otwieramy do nas dostęp z własnej sieci danego operatora - przed którego złośliwymi użytkownikami ochroni nas jedynie nasz własny firewall.
Ponadto warto zauważyć, że nawet tak banalny system jak Windows 2000 pozwala przerzucać ruch w trybie bridge albo za pomocą dzielenia łącza - wtedy w szczególności warto ograniczyć albo taką opcję w ogóle, albo móc filtrować to, co przez komputer przechodzi. Nasz zysk z użyczania dostępu do sieci może się zamienić w poważne problemy, jeśli ktoś poprzez to udostępnione połączenie narobi ambarasu…

Podsumowanie, czyli co powinna potrafić zapora ogniowa
W artykule omawiając rózne sprawy pominąłem pastwienie się szczegółowo nad DMZ czy VPN, bo to także wykracza poza (i tak straszenie rozszerzone) ramy postawionego na wstępie pytania. A jaka jest odpowiedź? Wydaje mi się, że dosyć jasna. Tak - firewall. Albo na jednej stacji, albo rozproszony, ale firewall. Filtrowanie ruchu jest potrzebne, wskazane i pożądane - w końcu to jedna z barier chroniąca nas przed wyciekiem pieniędzy: albo cennych danych, albo dla ‘pana od komputerów’ na doprowadzenie systemu do porządku.

Na zakończenie lista cech - co taki firewall powinien umieć?
• Uruchamiać się przy starcie systemu, tak aby być gotowym już wtedy, gdy jest nadany adres i możliwa komunikacja z systemem z zewnątrz, przed uruchomieniem pozostałych usług opartych na sieci innej niż pętla wewnętrzna
• Umożliwiać filtrowanie nie tylko ruchu przychodzącego, co odcina nas od hakjeruff w Sieci, ale także ruchu wychodzącego, co pozwala w jakimś sensie zabezpieczyć się przed własnymi błędami
• Umożliwiać kontrolę jaka aplikacja może wysyłać dany rodzaj ruchu - po co np. zegar systemowy miałby łączyć się z portem innym niż ntp/daytime? Po co przeglądarce ruch na port 25?
• Tworzenie reguł w nawiązaniu do konkretnych interfejsów/typów interfejsów.
• Tworzenie reguł czasowych - np. otwórz ten port na tą sesję/na 30 minut
• Zawierać dużą ilość predefiniowanych reguł pozwalających na automagiczną konfigurację znanych (i/lub podpisanych cyfrowo) aplikacji wraz z aktualizacją tej listy.
• W miarę możliwości filtrować w warstwie aplikacji, tak aby odfiltrowywać ataki na przypadkowo uruchomionego na stacji roboczej IIS czy SQL Server (WMSDE/MSDE) czy linuxowe odpowiedniki.
• Wyświetlać jasne komunikaty, że jakieś niepokojące zdarzenie ma miejsce - i to najlepiej w ilości niepozwalającej przejść obojętnie, albo miec opcję wysyłania takich ostrzeżeń do znajomego pana od komputerów/działu IT.
• Monitorować tworzone ad-hoc interfejsy (BT, GPRS, WiFi) i w zależności od polityki albo je wyłączać albo chronić.
• Monitorować ruch przechodzący przez maszynę, jeśli prowadzi routing.
• Móc całkowicie, definitywnie odłączyć maszynę od sieci - tak, żeby była potrzebna fizyczna interwencja administratora.
• Tworzyć zapisy swoich działań i móc raportować je do systemów zewnętrznych.

(1) W Windows Vista i w Longhorn serwer został/zostanie zaimplementowany wewnętrznie protokół p2p, który pewnie pozwoli na rozproszone i szybkie składowanie danych w dużych skupiskach i pozwoli(?) wykorzystać nadmiar pamięci masowej na stacjach roboczych

Sprawa wydawałaby się bananalna. Pakiety wchodzą z internetu (interfejs zewnętrzny, zewnętrzny IP) do routera i mają trafić do jakiegoś komputera w sieci. Router robi jakąś maskaradę sieci wewnętrznej. Ponieważ chcemy przejąć w tejże sieci wewnętrznej pulpit, powiedzmy, że to będzie WXP Pro, czyli interesuje nas port 3389. Zakładamy, że port na który wchodzą pakiety, to port 33089
OK - czyli do tej pory mamy:

• zewnętrzny IP routera (np. 193.213.32.4),
• wewnętrzny IP/sieć routera (np. 172.16.34.1/16),
• port routera: 33089
• adres WXP (np. 172.16.34.56),
• port WXP: 3389
• swój adres: 83.24.240.244

Sprawa banalna, opisana wszędzie, wystarczy wykonać dwa polecenia:

• /sbin/iptables -A PREROUTING -t nat -s 83.24.240.244 -d 193.213.32.4 –dport 33089 -j DNAT –to-destination 172.16.34.56:3389
• /sbin/iptables -A FORWARD -d 172.16.34.56 -p tcp –dport 3389 -j ACCEPT

Pierwsza z reguł mówi, że kazdy pakiet wchodzący z sieci zewnętrznej, kierowany na IP 193.213.32.4, port 33089 powinien być przekierowywany na maszynę o IP 172.16.34.56 i port 3389. Jest to reguła sprawdzana zanim zostanie podjęta jakakolwiek decyzja o routingu. Pakiety wpadają sobie do firewalla, podejmowana jest decyzja o routingu, ponieważ sieć docelowa jest wśród tych, które firewall osbługuje, to wrzuca pakiet do łańcucha forward, stąd konieczność (reguła 2) umożliwienia takiego właśnie ruchu.

Banalna sprawa, nieprawdaż? Gdzie ten haczyk? Cóż, wszystko działa oprócz tego, że TU nie działa. Otóż komputer kliencki ma swojego firewalla, który to spryciarz dopuszcza tylko połączenia z sieci wewnętrznej, (co łatwo sprawdzić, bo odrzuca połączenia z zewnątrz, a telnet na port działa). Zastosowany tu DNAT niestety nie tłumaczy adresu źródłowego na adres lokalny i pozostawia 83.24.240.244, co klient od razu ubija - pojawia się konieczność szukania zagrody, znaczy obejścia.
W tym momencie szkoły są dwie: falenicka i otwocka. Albo nie mamy czasu, olewamy sprawę, komfigurujemy tunel i voila, jesteśmy w środku i mamy dostęp do maszyny, albo nie mamy czasu, niemniej pokombinujemy z iptables. Pierwsza rzecz, która się nasuwa, to przeróbka pakietu. Niestety tablica mangle nie do tego została stworzona, żeby przerabiać takie cuda, więc nie tam. Są polecenia conntracka zamiany adresów, ale one raczej nie mają tu zastosowania. Rozwiązanie sprawy leży znów w NATce. Tym razem jednak na wyjściu.

• iptables -A POSTROUTING -t nat -s 83.24.240.244 -d 172.16.34.56 -p tcp –dport 3389 -j SNAT –to 172.16.34.1

Cóż to robi? Bada pakiet już wychodżacy z routera i jeśli spełnia on warunki źródła, celu, portu… to robi NAT (zwany popularnie maskaradą) zamianiejąc jak to w nacie bywa adresy źródła (-s), ukrywając je za adresem bramy. Nie ukrywam, że przez dłuższą chwilę nie przyszło mi do głowy, że to może być tak banalne (przecież to zwykły NAT, tylko na opak), niemniej szybka, nocna lektura dokumentacji pozwala na usprawnienie procesów myślowych.

Jedyne co mnie zastanawia, to fakt, że zawsze najlepsze (czytaj: działające w zadowalający sposób. ok, po prostu działające) rozwiązanie człowiek znajduje na końcu. Może dlatego, że dalej nie szuka?

Dziś dowiedziałem się o istnieniu stworzenia zwanego jak w tytule. Jest to relatywnie ciekawe zwierzę, pozwalające na indeksowanie i przeszukiwanie infrastruktury wewnętrznej przedsiębiorstwa - tej, która niedostępna jest z zewnątrz sieci: serwerów plikowych czy też stron intranetowych. Rozwiązanie ciekawe, szczególnie, że niewielkie (1U) i łatwe w instalacji. Podejrzewam, że relatywnie niedrogie, biorąc pod uwagę, że najmniejsza wersja kosztuje circa 2000$ (i co roku circa 1000$ abo). Dużym plusem jest oczywiście fakt, że ma się fajną wyszukiwarkę i wierzy, że nie wypuszcza ona informacji na zewnątrz.

Co mi się w tym niepodoba? Cóż - brak rozbudowanego interfejsu bezpieczeństwa, brak integracji z jakimś protokołem autoryzacyjnym. Nie pierwszy raz wiadomo, że wynalazki google pozwalają na wyszukiwanie informacji, które nie zawsze powinny trafić do szerokiego spektrum odbiorców. W tym wypadku jest niestety podobnie - google appliance potrafi znaleźć wszystko i wszystko odbiorcy zaserwować. Bez oglądania się na poziom zabezpieczeń, dostępów. Wyszukiwarka jest dostępna każdemu i każdemu zaserwuje zgromadzone informacje
Co prawda z dostępnych informacji wynika, że wersje entreprise mają już przyjemną(?) integrację, ale Enter Price version…

Jak pisałem na początku roku, wersja etch systemu debian używać będzie (w końcu) secure-apt, tj. pliki zawierające poprawki będą podpisywane, a klucze będą dystrybuowane w podpisanej paczce. Taka architektura rodzie pewne problemy - ale największym problemem jest nieumiejętność jej wykorzystania przez sam projekt debian Przykład? Dziś próba apt-get update kończy się komunikatem:

W: There are no public key available for the following key IDs:
A70DAF536070D3A1
W: You may want to run apt-get update to correct these problems

Oczywiście rozwiązanie jest proste - wystarczy dodać ten klucz i go pobrać (jeśli się nie mylę, to ostateczny klucz wydania etch), niemniej nie po to jest tworzony pakiet z kluczami, żebym sam je sobie dodawał do keyringa! Jeśli będę dodawał wszystko jak leci, to równie dobrze pakiety mogą być niepodpisywane…

Jak to zrobić?

Ciekawa wyszukiwarka kodu… Co jest śmieszniejsze, wyszukiwarka ciekawych komentarzy w kodzie. Chociaż znając (nie tylko) swój styl nazywania zmiennych tymczasowych i komentowania kodu to jestem zdziwiony jak rzadko występuje tam bardzo popularne słowo zmiennej tymczasowej i komunikatów debugujących…

Swoją drogą, co już zostało zauważone - wyszukiwarka otwiera kolejny wektor ataku, bo ileż osób hardcoduje w plikach include w PHP hasła dostępu do baz danych, użytkowników i inne przydatne dla szukającego informacje…