Доброго времени суток всем !

есть модуль ядра написаный на Си который ловит пакеты на 80(http) порт, анализирует GET запрос (т.е. пропускает handshakе т.к. неизвесно к какой страничке в конечном итоге пойдёт запрос) и принимает решение дропнуть или пропустить пакет.

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

сейчас пробую сделать это дело следующим образом

1 - модуль ядра, при запрещённом GET, шлёт через netlink в userspase следующую структуру



2 - в userspase демон эту структуру ловит и по идее(судя по анализу с wireshark) должен отправить 2 пакета, ACK (seq=ACKb, ack_seq=345) и ACK(seq=ACKb, ack_seq=345)+PSH+нагрузка, соответственно выставив адреса, порты, посчитав контрольную сумму TCP.

но пакеты с выставленный ACK и ACK+PSH не отправляются (tcpdump на сервере и wireshark на клиенте не видят их), при этом sendto ошибок не возвращает.

далее попробовал проанализировать, отправляются пакеты PSH, FIN+ACK, SIN+ACK, RST, и остальные вменяемые и невменяемые связки
при этом если saddr поставить левый и выставить seq и ack из присланой модулем структуры, то пакеты отправляются и принимаются, но при этом seq и ack_seq установленны в 1 а не в те значения что я выставил


вопщем прошу помощи в понимании как правильно послать поддельный пакет с ответом http, или возможно другой алгоритм решение поставленной задачи.

заранее благодарен за помощь !
 

да, чуть не забыл,
сервер CentOS 6.4
клиент WinXp SP3
оба в VirtualBox

Как-то не вяжется первое со вторым.


И в чём же задача?

может не так выразился ...
пропускается 3 пакета установки связи, т.е.

клиент -> SIN -> HTTP сервер
клиент <- SIN, ACK <- HTTP сервер
клиент -> ACK -> HTTP сервер

эти пакеты не несут нагрузки

а вот 4-ый пакет идёт от клиента, PSH+ACK+нагрузка, а в нагрузке как раз 

на основе этого и принимается решение о дальнейшей судьбе пакета



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

с уважением !

Это сообщение отредактировал(а) bodigard - 15.5.2013, 06:42

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

Я согласен с rsm, это всё функции прокси. Тем более что не всё, что http, то 80ый порт.


Скорее всего ядро-то и режет Ваши поддельные пакеты... Они не выглядят для ядра достаточно естественными...



Смысл этого действия? Логгирование?



А сам модуль ядра не может такой пакет сформировать, раз уж он разбирается в HTTP запросах? И заодно отправить пакет серверу о разрыве соединения...

Это сообщение отредактировал(а) feodorv - 15.5.2013, 22:10

верно, но в моём случае он не применим, во первых после прохождения через сквиду пакет дальше полетит с IP сквида, во вторых он просто загнётся на моём объёме трафика.


если не трудно, разьясните поподробнее почему это является угрозой безопасности ?


тоже так думаю, но не понятно почему тогда например PSH+payload, FIN+ACK, RST, или даже совсем невменяемый SIN+FIN+ACK+PSH+RST+URG для него естественны.


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


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

меня вот гложет, почему ядро подменяет seq и ack_seq ...

с уважением !

Это сообщение отредактировал(а) bodigard - 16.5.2013, 07:06

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


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


Во-первых, код ядра требует архивнимательной разработки, ибо малейшая ошибка может привести к kernel panic. Во-вторых, разбор HTTP внутри ядра даёт любому злоумышленнику возможность повысить привилегии или уронить систему, тупо отправив специально сформированный запрос. Перед тем как начать разработку, стоило бы погуглить, не пытался ли кто-нибудь уже сделать подобное. Я нашёл два проекта: TUX web server и kHTTPd, оба мертвы много лет. Что в целом вполне логично - риск создания дыры в безопасности на уровне ядра перевешивает любые другие доводы, какими бы привлекательными они ни казались. Поиграться на localhost'е из чисто академического интереса это ещё куда ни шло, но ставить такой софт на сервер не станет ни один вменяемый админ.

Трудно сказать. Может, на машине поднят NAT, он точно ничего такого не пропустит. Может, по HTTP вы ходите с сервера, тогда ядро проверит, тот ли процесс сгенерировал пакет. Может, какие-то дополнительные опции в ядре прописаны, кто знает. Может, Вы неправильно формируете пакеты)))

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


сейчас тестовая нагрузка 150 Мбит\с, в реальности думаю нужно чтоб обслуживал >1Гбит\с, всё это http трафик.
пробовал для решения этой задачи использовать snort (понятно что не для того он предназначен, но решить задачу он мог), но вот только он загнулся на ~5-7Мбит\с


совершенно согласен, потому всё сначала тестируется на виртуалке а только потом выставляется на тестовый опять-же сервер.


разбор заключается в поиске, в пакете с нагрузкой HTTP, заголовка GET и поля Host:, сравнении значений этих полей со списком запрета и на основании этой проверки принятии решение пропустить/дропнуть, если заголовка GET и/или поля Host: в нагрезке нет, то пакет просто пропускается.
из этого получается, что любой, пусть даже специально сформированный запрос, либо пройдёт проверку и полетит дальше либо отбросится.
при этом код ядра строился по принципу "минимум примочек, максимум надёжности", но 1ну примочку всё-же нужно, это какраз вернуть страничку пользователю, ибо пользователя нужно уважать 


гуглил, и не 1н день, но того что нужно нет в природе. TUX web server и kHTTPd это веб сервера уровня ядра, и тут согласен с вами, нечего им в ядре делать. Мне-же как Вы уже поняли нужен не веб сервер и даже не прокси сервер, но нужен максимально производительный фильтр http запросов на уровне заголовка http, остальной http контент меня не интересует.



поклон Вам, натолкнули на мысль, нужно проверить, отпишусь получится или нет ...

с уважением !

Это сообщение отредактировал(а) bodigard - 17.5.2013, 07:22

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

при этом я к примеру из userspase отправляю пакет с ack_seq = htonl(457), ловлю его в ядре(просто ради проверки) в NF_INET_LOCAL_OUT или NF_INET_POST_ROUTING, и у него ack_seq тот который я выставил, но tcpdump показывает другое значение, может есть соображения как это обойти ?


по HTTP с сервера точно никуда не хожу, httpd там тоже остановлен, опции ядра не менял.
пакет формирую так


с уважением !