Pytania o pakiety IP2 i odwrotny DNS oraz problem z pingiem

Problem: Po zainstalowaniu zapory filtrującej pakiety okazało się, że w sieci LAN pojawiło się mnóstwo pakietów IP2. Co to za pakiety i czy nie stanowią zagrożenia?

Rozwiązanie: Pakiety IP2 są tworzone przez protokół IGMP (Internet Group Management Protocol) i rozsyłane przez rutery. Za ich pomocą rutery sprawdzają, czy w sieci istnieją grupy multicast i jakie komputery wchodzą w ich skład. Rutery wysyłają w regularnych odstępach czasu pytania mające postać specyficznych pakietów multicast. W przypadku pakietów rozgłoszeniowych (broadcast) adresatem są stacje 255.255.255.255, w tym przypadku - 224.0.0.1. Stacje odbierające takie pytanie generują jednorazową odpowiedź host membership report, informując ruter, że są członkiem danej grupy multicast. Jeśli stacja stwierdza, że inna, należąca do tej samej grupy wysłała już wcześniej odpowiedź, to rezygnuje z wysyłania informacji. Rutery nie muszą przy tym śledzić wszystkich komputerów należących do każdej grupy multicast. Muszą jedynie dysponować listą wyszczególniającą aktywne grupy pracujące w sieci. Jeśli ruter nie odbierze od komputera wchodzącego w skład konkretnej grupy odpowiedzi host member report (na którą czeka nie dłużej, niż zostało to wcześniej określone), to zakłada, że grupa jest nieaktywna i w konsekwencji nie będzie do niej wysyłać pakietów multicast.

Protokół IGMP najczęściej jest używany do konfigurowania połączeń punkt-punkt między ruterami a hostami i nie stanowi dla sieci LAN żadnego zagrożenia.

Problem: Podczas ostatniego ataku wirusa SoBig.F byliśmy przekonani, że nasz serwer pocztowy jest należycie chroniony. Okazało się jednak, że mamy kłopoty. Kilku dostawców internetowych wciągnęło nas na jakieś listy i od tej pory nasza poczta nie jest przez nich obsługiwana. Powiedziano nam, że problem będzie rozwiązany wtedy, gdy utworzymy tzw. odwrotny DNS.

Rozwiązanie: Odwrotny DNS znajduje się w tych miejscach, w których serwer DNS konwertuje w pełni kwalifikowaną nazwę hosta na numer IP (dzięki któremu rutery mogą przesyłać dane z miejsca A do miejsca B). Odwrotny DNS pozwala serwerowi odbierającemu pocztę zwrócić się do autoryzowanych serwerów DNS obsługujących domenę i zweryfikować, czy host wysyłający pocztę rzeczywiście istnieje w danej domenie i ma taki adres IP, jaki został podany przez nadawcę. Autoryzowany serwer DNS jest zawsze traktowany jako ostateczne i wiarygodne źródło informacji o danej domenie. A takie informacje mogą być udostępnione tylko przez autoryzowany, a nie dowolny serwer DNS.

Zawartość strefy (pliku) odwrotnego DNS znajdująca się na serwerze DNS jest podobna do zawartości regularnej strefy, z tą różnicą, że zobaczymy tu wpisy PTR (od słowa "pointer"), które powinny odpowiadać wszystkim wpisom (zgodnie z odwzorowaniem jeden-do-jednego) umieszczonym w regularnej strefie lub strefach znajdujących się na serwerze DNS. Nazwa strefy (pliku) też wygląda nieco inaczej. Zamiast nazwy w rodzaju moja_firma.pl, zobaczymy coś, co wygląda jak część zakresu adresu IP dostarczonego przez usługodawcę internetowego (ale w odwrotnej kolejności z dopiskiem IN-ADDR.ARPA). Są dwie metody zawiadywania odwrotnym DNS. Jeśli usługodawca internetowy zdecydował, że serwer DNS będzie się znajdował u nas, możemy to zrobić sami. Musimy się wtedy zapoznać z materiałami technicznymi opisującymi w szczegółach proces budowania odwrotnego DNS. Jeśli nie, musimy dostarczyć usługodawcy internetowemu komplet informacji o naszej domenie, tak aby mógł zbudować u siebie odwrotny DNS.

Problem: Żaden komputer ani inne urządzenie pracujące w sieci LAN nie odpowiada na żądania ping wysyłane z mojego serwera NT. Na ekranie pojawia się komunikat - PING: transmit failed, Error Code 65. Polecenie ping 127.0.0.1 pracuje poprawnie, a serwer NT odpowiada na żądania ping generowane przez inne komputery pracujące w sieci. Używając tego samego połączenia, komputer odbiera e-maile i korzysta z usług internetowych; inne komputery mogą używać zasobów serwera NT. Odinstalowałem protokół TCP/IP, zainstalowałem go ponownie i skonfigurowałem. Zainstalowałem też nową kartę sieciową.

Rozwiązanie: Kilka pożytecznych kroków już zostało wykonanych. Komunikat o błędzie 65 może być mylący. Proszę najpierw usunąć z komputera całą obsługę sieci. Ponieważ protokół TCP/IP był już usuwany i ponownie instalowany, problem wydaje się dotyczyć tego obszaru. A więc po kolei: wyłączamy serwer, usuwamy kartę sieciową, włączamy serwer, odinstalowujemy wszystkie usługi sieciowe, uruchamiamy ponownie serwer (reboot) i sprawdzamy, czy pracuje poprawnie pod nieobecność sieci. Wyłączamy serwer, instalujemy kartę sieciową, włączamy serwer, instalujemy usługi sieciowe i instalujemy ponownie ostatni pakiet serwisowy (NT Service Pack). W przypadku systemu NT 4 powinien to być Service Pack 6. To powinno pomóc.