Czy implementacja zawiera pewne dodatkowe polecenia?

Niektóre implementacje protokołów zawierają dodatkowe polecenia diagnostyczne lub administracyjne, które nie są zdefiniowane w protokole. Mogą one być źle zaimplementowane lub nieprzemyślane i bardziej ryzykowne od tych, które definiuje protokół. Najsłynniejszym przykładem jest robak Morrisa z 199 roku. Posługiwał się on specjalnym poleceniem diagnostycznym SMTP, dzięki któremu mógł nakazać Sendmailowi, aby wykonał dowolne polecenie. Polecenie diagnostyczne nie było zdefiniowane w protokole SMTP.

Co innego może trafić do mojej sieci, jeśli dopuszczę tę usługę? Przypuśćmy, że ktoś opracuje protokół idealny taki, który zabezpiecza klienta przed serwerem i vice versa, bezpiecznie szyfruje dane, a wszystkie jego implementacje są całkowicie odporne na atak. Czy możesz po prostu przepuszczać ten protokół do wszystkich komputerów w swojej sieci? Nie, ponieważ nie możesz zagwarantować, że każdy komputer zewnętrzny i wewnętrzny używa właśnie tego protokołu właśnie w tym porcie.

Nie ma żadnej gwarancji, że ruch w danym porcie używa protokołu, którym jesteś zainteresowany. Dotyczy to zwłaszcza tych protokołów, które używają wielu portów albo portów o numerach powyżej 124 (gdzie numery portów nie są przydzielane indywidualnym protokołom), ale może się zdarzyć w przypadku każdego protokołu i numeru portu. Istnieją na przykład programy, które wysyłają protokoły inne niż HTTP do portu , ponieważ firewalle często przepuszczają cały ruch kierowany do tego portu.

Ogólnie rzecz biorąc, istnieją dwa sposoby upewnienia się, że odbierane pakiety należą do oczekiwanego protokołu. Jeden polega na przepuszczeniu ich przez system pośredniczący albo przez inteligentny filtr pakietów, który będzie je sprawdzał drugi polega na kontrolowaniu hostów, do których mogą trafiać pakiety. Konstrukcja protokołu ma często duży wpływ na możliwość zastosowania tych rozwiązań.

Jeśli używasz systemu pośredniczącego lub inteligentnego filtru pakietów, aby upewnić się, że przepuszczasz tylko oczekiwane protokoły, musi istnieć sposób odróżniania pakietów ważnych od nieważnych. Nie uda się to, jeśli protokół jest szyfrowany, bardzo skomplikowany albo bardzo ogólny. Jeśli protokół posługuje się kompresją albo w inny sposób zmienia położenie ważnych danych, jego weryfikacja może być za wolna, aby była praktyczna. W takiej sytuacji musisz albo kontrolować hosty, które korzystają z portów dla tego protokołu, albo pogodzić się z tym, że ludzie będą używali innych protokołów.

Leave a reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>