реклама на сайте
подробности

 
 
3 страниц V   1 2 3 >  
Reply to this topicStart new topic
> Защита сервера для GPRS приложений, Как практически реализовать?
MKdemiurg
сообщение Jun 29 2011, 07:37
Сообщение #1


Знающий
****

Группа: Свой
Сообщений: 624
Регистрация: 15-06-10
Из: Россия
Пользователь №: 57 939



Написал собственный TCPшный сервак для своих устройств телеметрии. Создал протокол, как первую меру по защите от несанкционированного использования. Теперь встал вопрос: А КАК защитить его от "левых" подключений и пустых пакетов( DoS атак) ? От пустых пакетов ввёл ограничение на буффер. Когда буффер подключения забит более чем на 100 байт,а идентификаторов протокола не обнаружено , то клиент обрубается. От подключений хотел ввести таймауты. Но тут меня постиг fail. Двум устройствам, находящихся на тестировании , в тчении нескольких суток назначаются одни и теже адреса типа xxx.xxx.62.121 xxx.xxx.62.120 xxx.xxx.62.122. При этом например адрес первого устройства, уже отключившегося, даётся второму. Но адрес этот "забанен" на 5-10 минут. Столкнулся вот с такой особенностью GPRS - поэтому пишу здесь.
Кто реализовывал сам такие дела подскажите - может забить на эти защиты? Или както по другому их реализовать ? Неохото потом перегружать сервак по 10 раз на дню.
Go to the top of the page
 
+Quote Post
Integral
сообщение Jun 29 2011, 09:27
Сообщение #2


Частый гость
**

Группа: Участник
Сообщений: 149
Регистрация: 9-08-08
Пользователь №: 39 519



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

Сообщение отредактировал Integral - Jun 29 2011, 09:28
Go to the top of the page
 
+Quote Post
MKdemiurg
сообщение Jun 29 2011, 10:14
Сообщение #3


Знающий
****

Группа: Свой
Сообщений: 624
Регистрация: 15-06-10
Из: Россия
Пользователь №: 57 939



Ну собственно что будет ловить фаервол? Сервер за NAT. Подключилось чтото на открытый порт, и давай швырять туда байты левые( это устранимо), а если подключиться 100-200 адресов. Будут висеть. Хотя да, можно настроить так чтобы фаервол рубал по минимальному потоку... Опять же а если GPRS глюкнет и стопор на 1 -2 минуты? Модуль то переподключиться сам - без этого никак.
Я IMEI и производственный номер устройства(моего, не модуля) использую. IMEI то можно и перешить. А комбинацию нереально "угадать".
Мне важна не безопасность данных - сниффер то негде поставить. А именно отказоустойчивость сервера.
Go to the top of the page
 
+Quote Post
Integral
сообщение Jun 29 2011, 11:05
Сообщение #4


Частый гость
**

Группа: Участник
Сообщений: 149
Регистрация: 9-08-08
Пользователь №: 39 519



ну у нас на ПК любие хорошие серверы берут уже готовые, так как создать самодельный хороший не реально, все уже есть готовое и отложенное и защищенное, я бы подганял бы готовый сервер под свои задачи
Go to the top of the page
 
+Quote Post
MKdemiurg
сообщение Jun 29 2011, 11:16
Сообщение #5


Знающий
****

Группа: Свой
Сообщений: 624
Регистрация: 15-06-10
Из: Россия
Пользователь №: 57 939



Ну я не с нуля его пишу, использую Qt библиотеку от Nokia. Тоже типовое решение (просто однопоточный асинхронный без блокировок) взял и в него парсер протокола и дрова БД инкапсулировал. Вообще мои опасния направлены ,так сказать, на то, что какой нибудь "шутник" прознает порт и IP сервера( они впринципе и скрываться не будут) и начнёт его целенаправлено валить. Когда на этот сервер конектятся несколько сот устройств - это не есть гуд. Маловероятно правда, что кому то это надо....
Go to the top of the page
 
+Quote Post
Integral
сообщение Jun 29 2011, 11:34
Сообщение #6


Частый гость
**

Группа: Участник
Сообщений: 149
Регистрация: 9-08-08
Пользователь №: 39 519



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

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

Сообщение отредактировал Integral - Jun 29 2011, 11:52
Go to the top of the page
 
+Quote Post
MKdemiurg
сообщение Jun 29 2011, 12:00
Сообщение #7


Знающий
****

Группа: Свой
Сообщений: 624
Регистрация: 15-06-10
Из: Россия
Пользователь №: 57 939



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

Цитата(Integral @ Jun 29 2011, 14:34) *
с другой стороны, не дружественный контакт может имитировать дружественного и забить все возможные макс подключения, тогда я незнаю))))

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

Go to the top of the page
 
+Quote Post
follow_me
сообщение Jun 29 2011, 12:13
Сообщение #8


Частый гость
**

Группа: Участник
Сообщений: 182
Регистрация: 4-11-10
Пользователь №: 60 646



Цитата(Integral @ Jun 29 2011, 13:34) *
придумать правила обмена данными для отличия хороших ИР от плохих, т.е. частота посылаемых данных, длина пакетов и т.д. и т.п., если вдруг любой с ИР не соотвецтвует "нормам" - отрубаем



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

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

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

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

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

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

Сообщение отредактировал follow_me - Jun 29 2011, 12:23
Go to the top of the page
 
+Quote Post
AlexandrY
сообщение Jun 29 2011, 12:17
Сообщение #9


Ally
******

Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050



Цитата(MKdemiurg @ Jun 29 2011, 10:37) *
Кто реализовывал сам такие дела подскажите - может забить на эти защиты? Или както по другому их реализовать ? Неохото потом перегружать сервак по 10 раз на дню.


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

Ну тогда VPN на внешнем роутере
Go to the top of the page
 
+Quote Post
follow_me
сообщение Jun 29 2011, 12:28
Сообщение #10


Частый гость
**

Группа: Участник
Сообщений: 182
Регистрация: 4-11-10
Пользователь №: 60 646



Цитата(AlexandrY @ Jun 29 2011, 14:17) *
Как можно понять, вы прогадали с GPRS модемом.
Есть модемы поддерживающие SSL.
Впрочем может SSL и на QT невмоготу поднять. wink.gif

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


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


Go to the top of the page
 
+Quote Post
MKdemiurg
сообщение Jun 29 2011, 12:45
Сообщение #11


Знающий
****

Группа: Свой
Сообщений: 624
Регистрация: 15-06-10
Из: Россия
Пользователь №: 57 939



Цитата(AlexandrY @ Jun 29 2011, 15:17) *
Как можно понять, вы прогадали с GPRS модемом.
Есть модемы поддерживающие SSL.
Впрочем может SSL и на QT невмоготу поднять. wink.gif

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


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

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

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

Сообщение отредактировал MKdemiurg - Jun 29 2011, 12:46
Go to the top of the page
 
+Quote Post
=F8=
сообщение Jun 29 2011, 12:53
Сообщение #12


Знающий
****

Группа: Свой
Сообщений: 567
Регистрация: 7-07-07
Из: Донецк
Пользователь №: 28 954



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

Не совсем так. Телит в своих GE865/868 обещает поддержку SSL.
Go to the top of the page
 
+Quote Post
Integral
сообщение Jun 29 2011, 12:55
Сообщение #13


Частый гость
**

Группа: Участник
Сообщений: 149
Регистрация: 9-08-08
Пользователь №: 39 519



Значит задача переходит в создание собственного фаервола.
Работать должен на низкоуровневом протоколе для обеспечения безопасности (и при работе с любыми другими протоколами)
Хакеры в студию)))
Go to the top of the page
 
+Quote Post
follow_me
сообщение Jun 29 2011, 12:56
Сообщение #14


Частый гость
**

Группа: Участник
Сообщений: 182
Регистрация: 4-11-10
Пользователь №: 60 646



тут посмотрел, по перебирал варианты - нет защиты идеальной, если захотеть сервис можно грохнуть не особо напрягаясь(ну если конечно вы не располагаете кластером серверов на мощном железе) - потому мой вам совет, не стоит решать проблемы которых ещё нет , да и которых может и не быть. любую защиту при желании сломают , какая бы она изощренная не была
Go to the top of the page
 
+Quote Post
AlexandrY
сообщение Jun 29 2011, 13:04
Сообщение #15


Ally
******

Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050



Цитата(follow_me @ Jun 29 2011, 15:28) *
ssl хорошо когда нужно обеспечить целостность и секретность данных , но от DoS он не спасет , если злоумышленник может слать raw пакеты то он тупо может обрывать ssl соединения, или наплодить кучу ожидающих согласования соединений


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

3 страниц V   1 2 3 >
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 18th July 2025 - 22:04
Рейтинг@Mail.ru


Страница сгенерированна за 0.0148 секунд с 7
ELECTRONIX ©2004-2016