Защита сервера для GPRS приложений, Как практически реализовать? Опции

[MKdemiurg]

Написал собственный TCPшный сервак для своих устройств телеметрии. Создал протокол, как первую меру по защите от несанкционированного использования. Теперь встал вопрос: А КАК защитить его от "левых" подключений и пустых пакетов( DoS атак) ? От пустых пакетов ввёл ограничение на буффер. Когда буффер подключения забит более чем на 100 байт,а идентификаторов протокола не обнаружено , то клиент обрубается. От подключений хотел ввести таймауты. Но тут меня постиг fail. Двум устройствам, находящихся на тестировании , в тчении нескольких суток назначаются одни и теже адреса типа xxx.xxx.62.121 xxx.xxx.62.120 xxx.xxx.62.122. При этом например адрес первого устройства, уже отключившегося, даётся второму. Но адрес этот "забанен" на 5-10 минут. Столкнулся вот с такой особенностью GPRS - поэтому пишу здесь.
Кто реализовывал сам такие дела подскажите - может забить на эти защиты? Или както по другому их реализовать ? Неохото потом перегружать сервак по 10 раз на дню.

[follow_me]

ну так вернемся к основному вопросу - каким образом SSL спасет сервис топикстартера от DoS ?

Как и говорилось раньше - он отличен для сохранения секретности но никак не для обеспечения отказоустойчивости из-за исчерпания ресурсов

есть множество грубых и примитивных атак которые реализуются в данном случае, только из-за того что злоумышленник будет сидеть с сервером и клиентами в одной,относительно небольшой, подсети (т.е. 1-10к вероятных клиентов).

Если пользователь может вручную формировать пакеты, то никто не мешает ему наводнить сервер запросами на создание сессии от фейковых клиентов из той же подсети. В таких ситуациях всё решается просто - адреса блокируются , но если они фейковые и по всему диапазону подсети то будут заблокированы и нормальные клиенты - если же нет , то они погрязнут в очередях ожидания соединения среди кучи весящих фейковых сессий.

грубо, грязно - но в данном случае чертовски эффективно и никак не защититься от такого

[AlexandrY]

ну так вернемся к основному вопросу - каким образом SSL спасет сервис топикстартера от DoS ?

есть множество грубых и примитивных атак которые реализуются в данном случае, только из-за того что злоумышленник будет сидеть с сервером и клиентами в одной,относительно небольшой, подсети (т.е. 1-10к вероятных клиентов).

.. то они погрязнут в очередях ожидания соединения среди кучи весящих фейковых сессий.

Мне кажется вы запутались в механизмах DoS атак.
Такие атаки страшны не на TCP и тем более IP уровнях, а страшны они на прикладном уровне где действительно идет много ресурсов на программный парсинг.
На уровне TCP аппаратура нисколько не напрягается от сплошного потока запросов. В самом напряженном случае отбой начнет давать ближайший к доморощенному хакеру роутер.
Никаких сессий на аппаратуре не возникает если приходит какой-то шальной IP пакет. Это все идет в реальном времени т.е. не создается очереди ответов даже.
Таймауты в TCP стеке практически не занимают ресурсов. Их может быть хоть миллион.
Для интереса посмотрите сколько на вашем компе существует включеных тредов и сколько ресурсов они потребляют.
А таймауты потребляют меньше чем треды на порядок.
Т.е. даже гипотетически DoS атаку из подсети провайдера один компьютер создать не может. Атакующих должно быть очень много физически и они должны свободно пропускаться на прикладной уровень, что с SSL им не удастся.