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

[MKdemiurg]

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

[MKdemiurg]

Так проблема, как понимаю, в том что автор не имеет навыков писания серьезных производительных серверов и при этом применяет сомнительную библиотеку.
У него естественная неуверенность, поэтому единственный путь это перенести аутентификацию на какие-то готовые движки, чтобы не напрягать свою самопальную реализацию прикладного протокола.
А с доморощенными DoS атаками уж как нибудь можно справится просто наращиванием производительности сервера. Главное, что этим не придется заниматься прикладной программе.

Действительно не имею, я системщик.
Я и интересовался доморощенными DoS атаками. Насколько велика вероятность того что кто то "просканит" IP и решит побаловаться?

SSL интересная штука, и на Qt это вполне реализуется (непонятно только почему Qt4 сомнительная библиотека? )? Но как реализовать это на 8 битном контроллере при 8МГц, в котором ещё 2 протокола крутится - памяти может и хватит, может даже и процессорного времени, но самому писать SSL - нереально. Вот думаю RSA прикрутить просто ради надёжности чтоли ))) . Там всё проще.

[=F8=]

Действительно не имею, я системщик.
Я и интересовался доморощенными DoS атаками. Насколько велика вероятность того что кто то "просканит" IP и решит побаловаться?

SSL интересная штука, и на Qt это вполне реализуется (непонятно только почему Qt4 сомнительная библиотека? )? Но как реализовать это на 8 битном контроллере при 8МГц, в котором ещё 2 протокола крутится - памяти может и хватит, может даже и процессорного времени, но самому писать SSL - нереально. Вот думаю RSA прикрутить просто ради надёжности чтоли ))) . Там всё проще.

На стороне сервера вам, собственно, ничего дополнительно писать не надо, просто ставите stunnel и все. На 8бит-8 МГц с ssl конечно тяжеловато будет, как впрочем RSA, плюс еще памяти минимум 64к надо. Кстати в ssl наиболее затратный по вычислениям момент это аутентификация и генерация сеансовых ключей которая происходит как-раз с помощью RSA. Но если вы в начале разработки то зачем ограничивать себя контроллером? PIC32MX695H стоит аж 8.5$ в розницу и 6.5$ в партии >1000. ssl тянет свободно. В серии STM32F103 есть контроллеры с объемом памяти 96к(в принципе можно и внешнюю память повесить, но дороже выйдет), а в 205/207 серии 128к. Тоже ssl без проблем потянут. Наконец можно подождать пока Telit свой встроенный ssl допилит.

[AlexandrY]

На стороне сервера вам, собственно, ничего дополнительно писать не надо, просто ставите stunnel и все. На 8бит-8 МГц с ssl конечно тяжеловато будет, как впрочем RSA, плюс еще памяти минимум 64к надо. Кстати в ssl наиболее затратный по вычислениям момент это аутентификация и генерация сеансовых ключей которая происходит как-раз с помощью RSA. Но если вы в начале разработки то зачем ограничивать себя контроллером? PIC32MX695H стоит аж 8.5$ в розницу и 6.5$ в партии >1000. ssl тянет свободно. В серии STM32F103 есть контроллеры с объемом памяти 96к(в принципе можно и внешнюю память повесить, но дороже выйдет), а в 205/207 серии 128к. Тоже ssl без проблем потянут. Наконец можно подождать пока Telit свой встроенный ssl допилит.

Хорошо, сделаю вид что никто не знает, что SSL в полный рост реализован в модемах Sierra Wireless

Но вообще слухи о SSL сильно преувеличены.
Никакой RSA там не нужен ибо в модемах есть защищенный сторонний канал передачи ключей по SMS.
Во вторых самый вычислительно долгий процесс это не RSA который по ресурсам не большем чем FFT требует, а вычисление длинного простого числа для алгоритма Дифи-Хелмана. Но опять же если ключами обменялись заранее то больше ничего не надо.
Ну а сеансовое шифрование в SSL может вестись по RC4.
Кто не знает, это примитивнейшая подстановка по индексу в массиве с перестановкой в массиве.
Даже на 8-и битном проце это пара десятков тактов. Самый быстрый алгоритм шифрации из известных.
Вообщем SSL работает на 8-и битниках работает влет и никаких сверхзатрат памяти не требует.

[=F8=]

Хорошо, сделаю вид что никто не знает, что SSL в полный рост реализован в модемах Sierra Wireless

Но вообще слухи о SSL сильно преувеличены.
Никакой RSA там не нужен ибо в модемах есть защищенный сторонний канал передачи ключей по SMS.
Во вторых самый вычислительно долгий процесс это не RSA который по ресурсам не большем чем FFT требует, а вычисление длинного простого числа для алгоритма Дифи-Хелмана. Но опять же если ключами обменялись заранее то больше ничего не надо.
Ну а сеансовое шифрование в SSL может вестись по RC4.
Кто не знает, это примитивнейшая подстановка по индексу в массиве с перестановкой в массиве.
Даже на 8-и битном проце это пара десятков тактов. Самый быстрый алгоритм шифрации из известных.
Вообщем SSL работает на 8-и битниках работает влет и никаких сверхзатрат памяти не требует.

Про Sierra Wireless не знал.

На счет передачи ключей по sms... ну как бы это уже не совсем ssl получается. Причем насколько я понял стоит задача обмена между девайсом с GSM модемом и сервером подключенным не через GSM модем. На счет Дифи-Хелмана. Если мне не изменяет память то аутоидентификация производится по Дифи-Хелмана ИЛИ с помощью RSA. Так зачем использовать более затратный алгоритм?(должен правда признаться что с Дифи-Хелмана не знаком поэтому вывод о затратности сделал с ваших слов, но в любом случае его поддержка необязательна)
На счет сеансового шифрования. Ну восьмибитник, с учетом скорости GPRS, и AES потянет, но там еще надо хеш по MD5 или SHA вычислять - тоже не мед.
А насчет памяти - максимальный размер буфера 32к отсюда и затраты. Можно конечно меньше сделать, но уже отклонение от стандарта, потеря универсальности.

Памяти всмысле флэш?

К сожалению RAM.

Использую мегу128 (только не надо смеяться - что познал на том и делаю- а познал только 8битки атмеловские). Стесняет то что впринципе вся переферия для контроллера подобрана и прошива уже написана(кроме шифрования - сначала оно и не предполагалось), а переходить на тотже STM32 надо время. А в конце сентября уже надо начать тестирование. Зимой хочу спрыгнуть на ARM (может на тот же STM32). Может на нём запустить RTOS со встроеной SSL?

А, что собственно смешного? Нормальный контроллер. А до осени еще времени ого-го. А какя RTOS имеет встроенный RTOS? ucLinux? Ну тут уж точно до сентября не справитесь. Да и во втроенную память не вложитесь, и вообще стрельба из пушки по воробьям. Я просто прикрутил polarssl к FreeRTOS задача совершенно не сложная. Просто пишите функции sslRead/sslWrite через которые эта библиотека читает/пишет из/в канал и sslOpen/sslClose для открытия закрытия сокета и все.

[AlexandrY]

Если мне не изменяет память то аутоидентификация производится по Дифи-Хелмана ИЛИ с помощью RSA.

С помощью RSA подписывают и расшифровывают сертификаты. Но если уж взялись расшифровывать сертификаты до должны уже прослеживать всю цепочку сетрификатов до главного авторизированого центра. А это куча запросов и обменов со сторонними серверами.
Я слабо верю, что вообще фриварные сорсы для мелких микроконтроллеров содержат движок парсинга сертификатов X.509, а значит RSA даже при желании непонятно куда там засунуть.

[=F8=]

С помощью RSA подписывают и расшифровывают сертификаты. Но если уж взялись расшифровывать сертификаты до должны уже прослеживать всю цепочку сетрификатов до главного авторизированого центра. А это куча запросов и обменов со сторонними серверами.
Я слабо верю, что вообще фриварные сорсы для мелких микроконтроллеров содержат движок парсинга сертификатов X.509, а значит RSA даже при желании непонятно куда там засунуть.

Не совсем так. С помощью RSA центр сертификации подписывает сертификаты, тем самым удостоверяя что предъявителю сертификата можно доверять, но кроме того сам сертификат представляет собой открытую часть RSA ключа предъявителя, который/которые(если идентифицируется и клиент) используется на этапе аутоидентификации и генерации сеансовых ключей.
У микроконтроллера не стоит задача работать с неопределенным числом сертификатов, поэтом все доверенные сертификаты просто хранятся в памяти. При установке соединения полученный сертификат сравнивается со списком допустимых сертификатов(тупо побайтно) и все. А дальше все как обычно.