Здравствуйте, netch80, Вы писали:

N>Ты что-то глобально путаешь. При SYN flood вообще соединение не устанавливается. А если прошёл TCP handshake (TCP ведь?), то адрес другой стороны известен. Даже если его эмулирует ближайший раутер.
похоже что ты прав.

N>Невозможно получить IP — может быть следствием того, что отправитель прислал RST. Тогда сам виноват, что не получил адрес ещё в accept(), а ждал возможности сделать getpeername() когда-нибудь потом.
кстати да, вариант...

N>А вот атака с подделкой sequence numbers — тут вполне возможна.
о чем речь?

N>И как ты собрался лечить этим удалённого клиента?
клиенты в этом проекте умеют автоапдейт, иначе они отключаются сервером сразу после проверки версии.

N>Например, message sequence numbers внутри потока (и тогда они тоже шифруются). После этого успешно расшифровать поддельный TCP уже не сможешь; а если смог — то ремотная программа взломана и вопрос именно в этом.
поясни плиз, не въезжаю...

Здравствуйте, netch80, Вы писали:

N>Ты что-то глобально путаешь. При SYN flood вообще соединение не устанавливается. А если прошёл TCP handshake (TCP ведь?), то адрес другой стороны известен. Даже если его эмулирует ближайший раутер.
похоже, ты прав...

N>Невозможно получить IP — может быть следствием того, что отправитель прислал RST. Тогда сам виноват, что не получил адрес ещё в accept(), а ждал возможности сделать getpeername() когда-нибудь потом.
кстати да, вариант...

N>А вот атака с подделкой sequence numbers — тут вполне возможна.
о чем речь?

N>И как ты собрался лечить этим удалённого клиента?
клиенты в этом проекте умеют автоапдейт, иначе они отключаются сервером сразу после проверки версии.

N>Например, message sequence numbers внутри потока (и тогда они тоже шифруются). После этого успешно расшифровать поддельный TCP уже не сможешь; а если смог — то ремотная программа взломана и вопрос именно в этом.
поясни плиз, не въезжаю...