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

[MKdemiurg]

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

[Integral]

а фаервол по защите от атак разве не помогает?
ИР адреса у модулей динамические, поэтому любие манипуляции (бан и т.п.) не совсем подходят, чето не коректное отрубаем, модуль должен сам переподключится, в качестве идентификатора каждого модуля можно отправлять ИМЕЙ, чето такое делал, тонкости уже призабыл, передаваемые данные можно шифровать

Сообщение отредактировал Integral - Jun 29 2011, 09:28

[MKdemiurg]

Ну собственно что будет ловить фаервол? Сервер за NAT. Подключилось чтото на открытый порт, и давай швырять туда байты левые( это устранимо), а если подключиться 100-200 адресов. Будут висеть. Хотя да, можно настроить так чтобы фаервол рубал по минимальному потоку... Опять же а если GPRS глюкнет и стопор на 1 -2 минуты? Модуль то переподключиться сам - без этого никак.
Я IMEI и производственный номер устройства(моего, не модуля) использую. IMEI то можно и перешить. А комбинацию нереально "угадать".
Мне важна не безопасность данных - сниффер то негде поставить. А именно отказоустойчивость сервера.

[Integral]

ну у нас на ПК любие хорошие серверы берут уже готовые, так как создать самодельный хороший не реально, все уже есть готовое и отложенное и защищенное, я бы подганял бы готовый сервер под свои задачи

[MKdemiurg]

Ну я не с нуля его пишу, использую Qt библиотеку от Nokia. Тоже типовое решение (просто однопоточный асинхронный без блокировок) взял и в него парсер протокола и дрова БД инкапсулировал. Вообще мои опасния направлены ,так сказать, на то, что какой нибудь "шутник" прознает порт и IP сервера( они впринципе и скрываться не будут) и начнёт его целенаправлено валить. Когда на этот сервер конектятся несколько сот устройств - это не есть гуд. Маловероятно правда, что кому то это надо....

[Integral]

ну я бы сделал так...
во первых ограничить можно число макс. конектов одновременно к серверу, все лишние отрубать
придумать правила обмена данными для отличия хороших ИР от плохих, т.е. частота посылаемых данных, длина пакетов и т.д. и т.п., если вдруг любой с ИР не соотвецтвует "нормам" - отрубаем, т.е., разобраться что означает "валить" сервер, дружественные клиенты должы работать в режимах обмена данным далеких от попыток завалить, таким образом можно будет легко отличить левых не дружественных контактов, которые или данные очень большие шлют, или слишком часто и т.д.

с другой стороны, не дружественный контакт может имитировать дружественного и забить все возможные макс подключения, тогда я не знаю))))

Сообщение отредактировал Integral - Jun 29 2011, 11:52

[MKdemiurg]

Наверно последую вашему совету и ограничу размер пакета до 1Кб ( буффер sim900) и кол-во пакетов за сеанс подключения. Практически всё равно проверить сложно ...

с другой стороны, не дружественный контакт может имитировать дружественного и забить все возможные макс подключения, тогда я незнаю))))

Тогда если не ограничивать - лимитировать подключения начнёт ОСь. Вот я и хотел обойти это включением таймингов в протокол передачи. Тогда будет сложнее "имитировать". Но это же GPRS - какие уж тут тайминги.

[follow_me]

придумать правила обмена данными для отличия хороших ИР от плохих, т.е. частота посылаемых данных, длина пакетов и т.д. и т.п., если вдруг любой с ИР не соотвецтвует "нормам" - отрубаем

ну и тут вы столкнетесь с тем что у вас адреса динамические и после переподключения меняются , и ваши баны ни к чему не приведу и могут только вредить нормальным клиентам которым будет выдан забаненный адрес

а как вам вариант такой

двухуровневая аутентификация устройств
два сервера - два порта , авторизации и коммуникационный , авторизации открыт , коммуникационный закрыт за фаерволом
первый делает хэндшейк который смогут пройти только доверенные узлы и заносит адрес в список доверенных ( или проще - фаерволом открывает порт коммуникационного сервера для данного IP)

все попытки сверх лимита(к примеру 3 неудачных хэндшейка) - пару минут чил-аут для данного IP

коммуникационный сервер просит иногда пройти повторную авторизацию

Хотя, как и у любой защиты тут тоже есть проблемы - например если злоумышленник может отправлять raw пакеты никто не мешает поменять адрес отправителя и тем самым тупо забить весь диапазон подсети , и все ваши клиенты отвалятся

Сообщение отредактировал follow_me - Jun 29 2011, 12:23

[AlexandrY]

Кто реализовывал сам такие дела подскажите - может забить на эти защиты? Или както по другому их реализовать ? Неохото потом перегружать сервак по 10 раз на дню.

Как можно понять, вы прогадали с GPRS модемом.
Есть модемы поддерживающие SSL.
Впрочем может SSL и на QT невмоготу поднять.

Ну тогда VPN на внешнем роутере

[follow_me]

Как можно понять, вы прогадали с GPRS модемом.
Есть модемы поддерживающие SSL.
Впрочем может SSL и на QT невмоготу поднять.

Ну тогда VPN на внешнем роутере

ssl хорошо когда нужно обеспечить целостность и секретность данных , но от DoS он не спасет , если злоумышленник может слать raw пакеты то он тупо может обрывать ssl соединения, или наплодить кучу ожидающих согласования соединений

[MKdemiurg]

Как можно понять, вы прогадали с GPRS модемом.
Есть модемы поддерживающие SSL.
Впрочем может SSL и на QT невмоготу поднять.

Ну тогда VPN на внешнем роутере

Не прогадал , т.к. себестоимость готового девайса ограничена 75$. А модули с поддержкой SSL думаю стоят напорядок дороже sim900. А сейчас может ещё Sim900R появится... И зачем мне шифрование данных, если я эти данные потом в открытый доступ выкладываю? Разве что зашифровать протокол? Но его можно узнать только если залезть в девайс и снять логи c UART. И опять же даже с SSL никто не запрещает подключиться к серверу и просто висеть ничего не посылая или посылая пустые пакеты.

ssl хорошо когда нужно обеспечить целостность и секретность данных , но от DoS он не спасет , если злоумышленник может слать raw пакеты то он тупо может обрывать ssl соединения, или наплодить кучу ожидающих согласования соединений

Вот и я о том же...

Сообщение отредактировал MKdemiurg - Jun 29 2011, 12:46

[=F8=]

ИНХО защита от DoS это как-бы не задача вашего сервера. На этот счет пусть у админа голова болит. Ваша задача просто не допустить несанкционированных подключений и тут SSL самое оно. Кстати есть куча реализаций которые без проблем лягут на достаточно "толстый" МК: polarssl(http://polarssl.org/), matrixssl(http://www.matrixssl.org/), axTSL(http://axtls.sourceforge.net/). Кроме того операторы могут создавать закрытую сеть с отдельным apn и, при необходимости подключать в эту сеть через VPN внешние IP. В этом случае вообще ничего защищать не надо.

А модули с поддержкой SSL думаю стоят напорядок дороже sim900

Не совсем так. Телит в своих GE865/868 обещает поддержку SSL.

[Integral]

Значит задача переходит в создание собственного фаервола.
Работать должен на низкоуровневом протоколе для обеспечения безопасности (и при работе с любыми другими протоколами)
Хакеры в студию)))

[follow_me]

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

[AlexandrY]

ssl хорошо когда нужно обеспечить целостность и секретность данных , но от DoS он не спасет , если злоумышленник может слать raw пакеты то он тупо может обрывать ssl соединения, или наплодить кучу ожидающих согласования соединений

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