LINUX.ORG.RU

знаю что нереально но спрошу ;)


0

0

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

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

Процесс соединения, насколько я въезжаю, таков:
    #  syn     #
кл. #---->     #
    #          #
    #<-syn+ack-#
    #          #
    #---ack--->#
    #          #

Три стадии, клиент посылает SYN пакет на соединение с хостом,
на сервере, если стоит FireWall и опция DROP_SYNFIN, 
запрос приложению перехватывается этим FireWall и пакет
syn+ack шлет он, приложение при этом еще ничего не знает.
Если DROP_SYNFIN не стоит, приложение отвечает 
syn+ack, отводя память под новое соединение (что и пресекает
DROP_SYN_FIN), далее клиент шлет подтверждение ACK и соединение
считается установленным.

О UDP я речь не веду тут все легко, но можно ли сделать
изменение сырцов на редирект-машине, чтобы конечная машина
'знала' кто к ней обращается?

      #   redir or  NAT     сервер
клиент #------>#-------------->#
      #       #               #
      #       #               #
10.0/8 (10.0/8)(192.168/16) (192.168/16)

Клиент обращается на приложение на сервере и
проходя через redir, source меняется на
NAT-машину. В этом случае подменить ничего
нельзя - тк как раз ACK пакетити будут слаться
на клиента - а он-то их не ждет и не ответит!
И сервер всегда будет видеть обращающуся машину
как адрес NAT из сети 192.168/16 

Но можно ли сохранить для сервера SRC клиента,
если редирект и сервер стоят на одной машине?
Например редирект находиться на одном порту,
а делает редирект на интерфейс своей же машины но
на другой порт - через какой-нибудь маскарадинг
в ядре (я не работал с ним на develop-уровне)
изменять в исходящих пакетиках addr? Для меня
главное - чтобы приложение клиента по sockaddr_in
определяло IP настоящего. Или это только 
на теории реально ?



anonymous

Re: знаю что нереально но спрошу ;)

Для такой штуки надо однозначно в исходниках ядра копаться,
а точнее скорее всего придется писать свой firewall и не использовать iptables.

"Для меня главное - чтобы приложение клиента по sockaddr_in
определяло IP настоящего."

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

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

Dead ★★★★ ()

Re: знаю что нереально но спрошу ;)

Да, опечатался - хотелось бы на серверном приложении иметь эту информацию.
То что на уровне ядра - это однозначно, но - это все таки реально? 
Без правки кода самого сервера? Поскольку менять код конечного 
приложения нельзя и  все программы получают данные о клиенте из 
структуры sockaddr_in - то логика подсказывает, что сделать 
это, получается, невозможно? Есть еще разные libcap-библиотеки, с
помощью которых можно дампить трафик - как на свою машину так и
вообще на интерфейсах, если делать это в promiscuse-режиме. 
Вот чисто теоретически - если на исходящем интерфейсе поставить
такой же теоретический фильтр, который в IP-пакете будет менять
IP источника - то приложение в логах напишет подмененный IP, но
'логическая' связь (по TCP) не установиться - тк тогда сервер будет
отсылать пакет ack на этот подмененный адрес?

Я знаю, что если этот ACK опять поймать на роутере и обработать  -
тогда схему можно реализовать (так ломаются сервера подменой IP -
подменивается в структуре SRC и начинается скан атакующей машины
до тех пор, пока пакет не будет резаться. А потом остается лишь
поймать ACK атакующим хостом и вновь сгенерить нужный пакет -
единственное что надо соблюдать, чтобы маршрут от атакуемой машины
к доверенной машине (чей IP ставим) был через man-in-middle хост ;)
Но это я так, отступление - у меня задача другая, чтобы 
например WWW-сервер находящийся на NAT знал кто к нему лезет...



anonymous ()

Re: знаю что нереально но спрошу ;)

В общем IMHO это возможно, но очень сложно....
Нужно конретно посидеть и посмотреть как реализовывается NAT в ядре.
Простеньким фильтром пакетов тут явно не обойдешься.
можно задаться вопросом в том, стоит ли оно того? :)

Dead ★★★★ ()

Re: знаю что нереально но спрошу ;)

Да, как работает НАТ я первым делом посмотрел. До безобразия примитивно: ловит запрос из внутренней сети, пишет соовт. dst - src в табличку, оставляет этот сокет открытым, а сам открывает свое соединение от порта > 1024 на dst, качает то что надо, закрывает соединение и ориентируюясь по табличке dst - src пишет в дескриптор данные. С UDP технология та же, немного отличается ICMP - как я понял из сырцов - когда клиент пингует чей-то хост, НАТ также пишет это в табличку, затем пытается пингануть сам. Если не удается - то он оставляет ICMP от клиента без ответа, если удается - то отсылает ответ. Т.е. это редирект и есть. Сырцы с смотрел на NATD и IPF из IPFilter.

anonymous ()

Re: знаю что нереально но спрошу ;)

Насчет стоит это или нет - а и сам не знаю. Потому что было бы полезно если было бы реально. Может кто жирную точку еще поставит, чтобы я не мучался ;) Я недавно откопал в сырцах ядра, что последний известный тип IP принадлежит протоколу SCTP. Как оказалось - над ним два года уже работают - он призван вскоре заменить TCP/UDP, по 20 лет уже. Изначально был проект по доработке TCP для потокового вещания на TCP для VoIP - но я никаких спецификаций и RFC не нашел - может девелоперы знают - где прочесть можно? Тут я о нем вспомнил потому, что несмотря на то что он в Beta- реализации, уверяют что любое приложение TCP/UDP сможет на нем фурычить.

anonymous ()

Re: знаю что нереально но спрошу ;)

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

DiMoN ★★★ ()

Re: знаю что нереально но спрошу ;)

Да, ты прав - это глупо, но я просто это написал в качестве примера - о возможности такой версии жить. Вообще, задача у меня стояла такая - есть машина с внешним IP на одном интерфейсе, и плюшевым - на другом интерфейсе. Внутри сети с плюшевыми IP (rfc1918) есть один WWW-сервер, к которому, чтобы можно было работать и за пределами сети, на НАТе сделан редирект 80/tcp. Вся проблема, что у http сервера есть ACL-листы, запрещающие доступ по IP. Поэтому мне стало интересно - если не менять код самого приложения, но можно написать и установить все что хочешь на НАТе и самом WWW - чтобы http-серверу пермаментно форвардился IP. Конкретно в моем случае нужно или на VPN перевести сеть, или дать www ресурсу внешний alias-ный IP, чтобы он одновременно в двух сетях был, а WWW-сервер чтобы IN_ADD_ANY слушал, но я не стал обрисовывать именно свою проблему - увлекаюсь еще программингом, поэтому и заинтересовался в этом вопросе, реально или нет. Давно бы проверил - да копаться еще самому нужно - чем внести изменения в src IP-пакета.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.