Ochrona przed niechcianymi pakietami

0

Załóżmy że mój serwer odbiera pakiety o następującej strukturze:

struct package
{
      char costam[32];
      char dane[64];
};
 

w momencie gdy ktoś wyśle do mojego serwera pakiet:

 
struct zly_pakiet
{
      int numer;
      flot inne;
      char zle[128];
};

powstają błędy. Moje pytanie: jak zabezpieczyć się przed niechcianymi pakietami?

0

;O
Sprawdzasz czy jest z listy adresow zaprzyjaznionych.
Sprawdzasz rozmiar danych.

0

Nie mam listy adresów zaprzyjaźnionych, powiedzmy że jest to serwer jakiejś gry. Rozmiar pakietu -ok, ale w takim razie jak rozwiązać problem z recv? Powiedzmy że oczekuje na pakiet o rozmiarze 32, a otrzymuje tylko 24(to jest ten zły pakiet) i moja funkcja czeka na odbiór pozostałych 8bajtów.

0

Latwiej by bylo jakbys powiedzial o co Ci chodzi.

W przedstawionej sytuacji bym wlepil 24 bajty do bufora tymczasowego i jechal dalej z przetwarzaniem pozostalych pakietow, ew. bym olal te 24 bajty. Glowny problem polega na tym, ze nie da sie sprawdzic czy otrzymane n bajtow, to te n bajtow o ktore nam chodzi, dlatego tez sie sprawdza rozmiar, mapuje na strukture i sprawdza jakies sumy czy cos takiego. Mniej-wiecej po to sie robi naglowki w sofcie.

Ja mam natomiast pytanie dlaczego oczekujesz otrzymania zlych bajtow? Jesli Ci ktos scrackuje klienta i wysle jakies randomowe (w tym kontekscie) dane to mozesz zakonczyc z nim polaczenie dodac do blacklisty i tyle.

0

Trzeba sprawdzić poprawność danych i ewentualnie sprawdzić czy dane pochodzą od poprawnego źródła.

Trochę mało informacji podałeś, ale może być coś takiego:
Najpierw wysyłasz nagłówek, który zawsze ma stały rozmiar i przesyłasz w nim rozmiar danych, jakieś dane identyfikujące klienta plus suma kontrolna takiego nagłówka. Odbierasz najpierw nagłówek(jeżeli będzie za mały to po prostu dostaniesz timeout, w innej sytuacji suma kontrolna się nie zgodzi).
Następnie odbierasz dane, możesz narzucić ich maksymalny rozmiar jakby ktoś chciał przesłać spreparowany nagłówek i olbrzymią ilość danych.

Żeby mieć raczej pewność, że dane pochodzą z dobrego źródła, możesz wysyłać na końcu wiadomości MAC(http://pl.wikipedia.org/wiki/Kod_uwierzytelniania_wiadomo%C5%9Bci). Np. zaszyfrowana suma kontrolna danych. Oczywiście kluczami, które nie są przesyłane. Zna je klient i serwer.

0

Chodzi mi o konkretną sytuację:

Mój serwer nasłuchuje na porcie X. Klient łączy się z moim serwerem i serwer oczekuje na pakiet:

struct package
{
      unsigned char type;
      char *data;
};
 

Klient wysyła ten pakiet typu 120, serwer odbiera i odczytuje typ pakietu-typ 120 czyli rozmiar np. 32bajty. Następnie odbiera resztę pakietu i porównuje odebrane wartości z czymś tam i jeżeli się zgadzają, dodaje klienta do jakiejś listy.

W pewnym momencie ktoś spamuje na adres i port X serwera (wysyła właśnie jakieś losowe pakiety). Nadchodzi ten moment, odbieram błędny pakiet od złego klienta - tutaj zaczynają się problemy. Powiedzmy że serwer odczytał z tego błędnego pakietu typ wynoszący 204. Serwer wie że pakiet typu 204 powinien mieć rozmiar 128bajtów i dąży do odebrania takiego pakietu. Jednak otrzymuje tylko jakieś śmiecie. Interesuje mnie jak rozwiązać ten problem. Będzie to proste w momencie, gdy serwer odczyta typ pakietu z poza obsługiwanego zakresu, ale co w momencie, gdy typ znajduje się w znanym zakresie?

0

Jak rozmiar się nie zgodzi to po prostu się rozłączyć i pakiet olać. Jak rozmiar też się zgodzi to sprawdzić jakąś sumę kontrolną, a lepiej MAC. Więcej nie ma co robić, bo żeby się zorientować czy pakiet jest poprawny i tak musisz go pobrać. Cudów nie ma, kryształowe kule nie działają ;)

0

Czyli najpierw serwer i klient za pomocą protokołu Diffiego-Hellmana tworzą klucz. Klient wysyła pakiet (nagłowek, zaszyfrowaną kluczem sumę kontrolną nagłówka i dane). Serwer odbiera pakiet, jeżeli coś się nie zgadza, to rozłącza się z klientem. Suma kontrolna nagłówka powinna być dołączona do każdego pakietu? To zawsze dodatkowe kilkadziesiąt bajtów do przesłania.

0

Rozwiązanie z sumą kontrolną jest bez sensu, jeśli atakujący pozna sposób generowania sum kontrolnych a na pewno musi być to zapisane w aplikacji klienckiej to i tak będzie wysyłał podrobione pakiety.
MAC jest na innym poziomie modelu OSI, poza tym nie zawsze można go odczytać więc to już totalna bzdura.
Po prostu musisz walidować wszystkie dane pochodzące od użytkownika czyli jak odbierzesz pakiet np. zawierający datę to musisz sprawdzić czy to faktycznie data, jeśli ma to być data z przeszłości to musisz sprawdzić czy faktycznie tak jest, jeśli oczekujesz liczby zmiennoprzecinkowej to sprawdzaj czy to faktycznie float. Jeśli oczekujesz loginu i hasła złożonego z liter [a..z, A..Z] to musisz sprawdzić czy faktycznie string z pakietu zawierta tylko te znaki - jeśli nie to loguj IP takiego delikwenta i zamknij z nim połączenie, lub jeśli nie grozi to stabilnością loguj pakiety próbując się dowiedzieć co kombinuje ten delikwent. Brak walidacji może przyczynić się do tego, że zrobisz sobie np. SQL injection jeśli korzystasz z bazy lub np. popsuć plik do którego zapisujesz przetworzone dane.
Przykładowo masz dane zapisane w pliku CVS oddzielone średnikami - wystarczy, że dowcipniś w polu loginu poda średnik i już plik się sypie, pomimo tego, że w kliencie zrobisz walidację przeciw wpisaniu średnika.
Pakiety często nie dochodzą w całości lub przychodzą posklejane - może nikt cie nie atakuje tylko nie bierzesz tego pod uwagę?

0

Na razie atakuje sam siebie. Czyli powiedzmy oczekuje pakietu o rozmiarze 64bajtów, otrzymuje mniej to z góry odrzucam te połączenie. Oczekuje 64bajty, otrzymałem 64bajty, serwer np. wykrył niedozwolone znaki więc również odrzucam. Tak mniej więcej ma to wyglądać?

1 użytkowników online, w tym zalogowanych: 0, gości: 1