[Programowanie C] Sockety i wiarygodność adresu IP klienta

[Rysiu]

Piszę aplikację na socketach w C.

Czy jako klient mogę się jakoś podszyć i zmienić swoje IP tak ze serwer wykryje (i w zapisywanych logach) będzie miał inne IP niż to faktyczne?

Chodzi mi o to czy to wystarczające zabezpieczenie sprawdzać czy ktoś łączy się z odpowiedniego adresu IP i wtedy autoryzować takie połączenie, czy jednak istnieje możliwość aby to obejść.

[Dario666]

Jedyne co na szybko mi przychodzi do głowy to atak zwany Man in the middle.

[apohawk]

Pytanie, co jest między aplikacją a klientem. Najprostsza zmiana IP to NAT i jest powszechnie stosowana np. na routerach udostępniających internet komputerom w sieci lokalnej. Można też zrobić spoofing, puścić własny pakiet, w którym wpiszemy jakieś dziwne IP. Często routery wycinają pakiety, które nadchodzą z niewłaściwej strony, czyli pakiet z IP źródłowym A pojawia się na interfejsie sieciowym, który nie jest interfejsem do wysyłania pakietów do adresu A.

[EDIT]
Może inaczej, co próbujesz zrobić?

[Rysiu]

Piszę kawałek serwera odpowiedzialnego za przyznawanie kredytów pomiędzy wieloma projektami BOINC (ujednolicony system przyznawania i emisji kredytów).

Część kliencka ma być wbudowana w validatora, który to będzie wysyłał odpowiednie zapytanie do owego serwera ile ma kredytów za określone zadanie o określonym czasie wykonywania przydzielić. W owym zapytaniu zawarte są wszystkie informacje niezbędne do obliczenia przyznanych ilości kredytów.

W informacji zwrotnej validator otrzymuje ilość kredytów jaką ma przydzielić userowi.

Aktualne zabezpieczenie polega jedynie na tym, że sprawdzam czy klient (validator) łączy się z odpowiedniego przypisanego do danego projektu adresu IP (jest on zapisany w odpowiedniej kolumnie i odpowiednim rekordzie w bazie danych).

Idealnie byłoby gdyby w bazie danych obok tego adresu IP znalazło się także hasło (inne dla każdego projektu) i wykorzystywane byłoby ono do szyfrowania/deszyfrowania przesyłanych wiadomości.

Kiedyś na potrzeby studiów i artykułu naukowego zaimplementowałem 3DES'a i myślałem, że tutaj jego wykorzystam ale okazało się, że wywala mi błąd pamięci (wcześniej - kilka lat temu - działał dobrze). Nie mam energii aby dochodzić co w nim nie gra.

Stąd też moje pytanie o bezpieczeństwo. Jako tako nie przesyłam tam, żadnych danych tajnych i szyfrowanie nie jest potrzebne. Potrzebna jednak jest jakaś autoryzacja klienta, aby nie mógł podłączyć się ktoś inny i narobić bajzlu. Teoretycznie to nic by nie szkodziło aby ktoś inny się podłączył. Bo co uzyska? Nic.

Problem jednak polega na tym, że serwer emisji kredytów na podstawie zapytań pochodzących z projektów BOINC buduje własną bazę danych kredytów użytkowników. Ta baza danych powinna być (co oczywiste) odbiciem lustrzanym oryginalnej, projektowej bazy danych (zawiera jednak tylko wycinek danych z ID userów i przypisanych do nich kredytami). W przypadku padu serwera projektu (np. pad dysku) zawsze można wydobyć ilość kredytów jaką posiada dany user bez jakiejkolwiek ewentualnej straty (bo przecież ta baza danych jest budowana w czasie rzeczywistym). W przypadku zwykłych backupów zawsze możemy stracić kredyty przydzielone zaraz po zrobieniu backupu.

Już jednak admin "z palca, ręcznie" nie wpisze kredytów danemu userowi (powstanie brak spójności baz, który może być w każdej chwili wykryty). Za bardzo także nie będzie miał możliwości modyfikacji validatora, bo ten będzie udostępniany jako już skompilowany (ewentualnie kompilowany z modyfikacjami na "zamówienie" i na życzenie admina projektu). Można odzyskać dane kodu źródłowego ze skompilowanego programu ale to już nie będzie takie proste.

Sprawa jest nieco skomplikowana - niemniej pierwszą wersję serwera już zaimplementowałem. Nie działa ona efektywnie przynajmniej z kilku powodów ale jakoś działa  %)

Gdyby ktoś był chętny do pomocy to proszę pisać.

[krzyszp]

Albo ja czegoś nie rozumiem, albo nieźle zamotałeś.
To ma chodzić jako projekt BOINC? Jaki "klient" na odpytywać projekt? Poco w ogóle, skoro można sparsować statsy z danego serwera?

[Rysiu]

Albo ja czegoś nie rozumiem, albo nieźle zamotałeś.
To ma chodzić jako projekt BOINC?

Gdzie tam, jako jaki projekt BOINC znowu. Toć to nie miałoby sensu jako projekt BOINC.

Poco w ogóle, skoro można sparsować statsy z danego serwera?

Tak tylko, że żadne statystyki zapisywane do plików nie są generowane w czasie rzeczywistym. Co jeżeli nie możemy sobie pozwolić na utratę nawet jednego kredytu?

Do tego dochodzi problem zaufania do admina (który może teraz z kredytami wszystko).

[krzyszp]

Wiesz, może kilku adminów da Ci wejście w system kredytowy, ale żeby wszyscy? Nie ma szans...

[apohawk]

1. Tzw. "problem zaufania do admina" będzie zawsze. W pewnym momencie musisz po prostu ludziom zaufać. Jakikolwiek system kontroli adminów napiszesz, będziesz musiał zaufać adminom systemu kontroli.
2. Zamiast bawić się z autoryzacją po IP i zabezpieczaniem tego, to załóż im normalne konta albo podpisy/szyfrowanie PGP/GnuPG komunikatów przesyłanych do ciebie i tyle.