Как Избежать DoS-атаки с помощью Сокетов Беркли в C++

Важное чтение: Проблема C10K

Использование потоков (или процессов) для каждого соединения делает код очень простым. Ограничение числа подключений на самом деле является ограничением числа потоков, которые ваша система может с комфортом выполнять в многозадачном режиме.

Использование асинхронного ввода-вывода для размещения всех сокетов в одном потоке - не такой простой код (красиво обернутый libevent и libev2 ), но он гораздо более масштабируемый - он ограничен количеством открытых файловых дескрипторов, которые позволяет ваша система, и - например, в последних сборках Linux - это может быть измерено миллионами! По этой причине большинство веб-серверов и других серверов используют асинхронный ввод-вывод.

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

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

Защита сетевого приложения с выходом в Интернет от вредоносных client - это совсем не тривиально и, вероятно, включает в себя все упомянутые вами продвинутые методы, а также некоторые! Например, часто часть ответственности перекладывается с кода приложения на уровень маршрутизатора или межсетевого экрана. Вы можете ограничить доступ только доверенными узлами или обнаруживать чрезмерные попытки подключения и ограничивать или блокировать их до того, как трафик попадет в ваше приложение.

То, что я делал раньше, чтобы помочь с этим (около 1997 :), заключалось в том, чтобы потребовать, чтобы магическое число было отправлено в течение определенного промежутка времени, иначе соединение будет закрыто.

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

Это не идеально, но для ваших текущих забот может помочь решить эту проблему и позволить не использовать ресурсы, создавая слишком много соединения.

Таким образом, для очистки требуется основной поток и второй поток, поэтому он не является однопоточным.

У меня вопрос, есть ли другие способы избежать такого атака?

Для сервера мне нужен таймер на уровне приложения:

• Буфер входных данных на соединение
• Тупой код чтения сокета считывает данные из сокета во входной буфер
• Приложение- специальный код анализирует содержимое входного буфера

. Специфический код приложения может разорвать соединение, связанное с входными буферами, которым было разрешено бездействовать в течение «слишком долгого времени».

Выполнение этого подразумевает асинхронный ввод-вывод или выделенный поток [-ов] ввода-вывода.