3

Я настраиваю межсетевой экран iptables, в настоящее время только для разрешения трафика http и https. Это работает, но по особенно странному правилу - я должен разрешить входящие соединения с портом источника 80.

Это не имеет смысла для меня, не должен ли входящий трафик иметь порт назначения 80?

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

# Set all major commands to DROP by default
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

# Allow HTTP and HTTPS
# Need to consider limiting to ESTABLISHED, RELATED for OUTPUT
# consider NEW for INPUT
# configure source ports in range 1024:65535

iptables -A INPUT -i eth0 -p tcp -m multiport --dports 80,443 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp -m multiport --sports 80,443 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp -m multiport --dports 80,443 -j ACCEPT

# ping from inside to outside
iptables -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT

# allow loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Outbound DNS
iptables -A OUTPUT -p udp -o eth0 --dport 53 -j ACCEPT
iptables -A INPUT -p udp -i eth0 --sport 53 -j ACCEPT

# Logging before Drop for troubleshooting
iptables -A INPUT -j LOG
iptables -A INPUT -j LOG
|источник

4 ответа4

2

Если веб-сервер ответил на ваш запрос с произвольного порта, то как ваша ОС узнает, что этот трафик отправляется в ваш браузер?

Вот как это работает, в общем:

  1. Ваш браузер хочет установить исходящее соединение с сервером, поэтому он запрашивает у сокета сокет.
  2. Если браузер не делает что-то странное, ему все равно, какой порт использует получаемый сокет на вашем конце, поэтому ОС назначает случайный свободный.
    • Для этого примера я буду использовать 53904 в качестве нашего случайного порта на стороне браузера.
  3. Браузер просит ОС подключить этот сокет к IP-адресу сервера (обычно находящемуся в DNS) и порту прослушивания (обычно 80 для обычного HTTP-сообщения или 443 для HTTPS; иногда в URL-адресе указывается что-то еще).
    • В этом примере мы предполагаем, что вы выполняете простой текстовый HTTP через порт 80.
  4. ОС отправляет запрос TCP-соединения (SYN) в адресат, указанный браузером, со следующими данными: исходный IP: IP-адрес вашего сетевого интерфейса; порт источника: 53904; IP-адрес назначения: IP-адрес сервера; порт назначения: 80.
  5. TCP-запрос направляется через сеть (-и) между вами и сервером.
    • Преобразование сетевых адресов (NAT) может изменить исходный IP-адрес (на IP-адрес маршрутизатора) и порт (на случайный, который маршрутизатор сопоставляет с исходным соединением, полученным от вас), но не влияет на пункт назначения.
    • Маршрутизатор, выполняющий NAT, будет прослушивать новый "исходный" порт и преобразовывать трафик ответов в ответы на исходный запрос вашего компьютера.
    • Для простоты я больше не буду вдаваться в NAT в этом примере; мы просто предположим, что и ваш адрес, и сервер являются уникальными общедоступными IP-адресами.
  6. Запрос поступает на порт сервера 80 (или 443 или что-то еще). Процесс веб-сервера уже сообщил операционной системе сервера, что он хотел бы accept входящие TCP-соединения через этот порт.
  7. ОС сервера создает и отправляет подтверждение (SYN-ACK) в ответ. Он должен иметь те же данные, что и входящий пакет, за исключением того, что источник и пункт назначения меняются местами: IP-адрес источника: IP-адрес сервера; исходный порт: 80; IP-адрес получателя: ваш IP; порт назначения: 53904.
  8. Этот ответ возвращается через Интернет к вашему компьютеру, где ваша ОС прослушивала, чтобы узнать, получает ли он SYN-ACK через порт 53904 с этого IP-адреса.
    • Есть также такая вещь, как "порядковые номера" и "номера подтверждения", которые используются для проверки того, что соединение является тем, каким оно должно быть, и для предотвращения подделки какого-либо другого компьютера, что вы пытаетесь установить связь с сервером.
    • Конечно, эта защита от фальсификации (подделки) сервера работает только в том случае, если злоумышленник не может наблюдать / перехватывать трафик, который вы отправляете. Значительная часть SSL / TLS, обеспечивающая безопасность HTTPS, представляет собой более надежный механизм аутентификации сервера.
  9. Ваша ОС получает SYN-ACK и отвечает собственным ACK, снова изменяя источник и назначение (или просто повторно используя исходный источник и назначение; то же самое).
  10. Теперь ваша система подтверждает соединение с обеих сторон, и ваша ОС сообщает браузеру, что теперь он может отправлять данные через сокет.
  11. Операционная система сервера, теперь получив подтверждение вашего компьютера (и проверив порядковые номера), создает новый сокет для использования программным обеспечением веб-сервера. Этот сокет используется для передачи трафика для только что завершенного TCP-соединения и привязан к порту 80 на IP-адресе сервера и к порту 53904 на вашем IP-адресе; он будет получать и отправлять данные через порт 80.

Оттуда браузер и веб-сервер передают HTTP друг другу по этому каналу TCP. Я не буду вдаваться в подробности этого, хотя. Это все лишь для того, чтобы проиллюстрировать, почему вашему брандмауэру необходимо разрешать входящие пакеты, отправленные с порта 80 сервера, если вы хотите получать HTTP-ответы от этого сервера.

|источник
1

Ты пишешь

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

Нет. Www.google.com будет отправлять с порта 80 на ваш случайный порт.

Точно так же любой веб-сервер, который вы запускаете, не просто прослушивает порт 80, он отправляет пакеты с портом источника 80.

И, конечно же, ваш веб-сервер не будет взаимодействовать с веб-сервером Google.

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

И когда вы заходите в Google, у вас есть случайный порт, открывающий ваш конец

Ваша путаница заключается в том, что вы не понимаете, что INPUT не имеет ничего общего с "входящим соединением". Это все входящие пакеты, включая входящие исходящие соединения.

Итак, ваш сервер прослушивает порты 80 и 443

Я не эксперт, но

Я собираюсь дать общую настройку, как описано в "На пути к идеальному набору правил" (или в том виде, в котором его используют те, кто на это указывает)

http://inai.de/documents/Perfect_Ruleset.pdf

Разрешить все

- Разрешить все установленные и связанные (связанные включает в себя новые подключения от него, такие как то, что требует старый протокол FTP - не то, что вы используете FTP. И это включает ошибки ICMP)

- Разрешить все пакеты на порты вашего сервера.

Таким образом, ваша политика будет

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

использование -m conntrack is и --ctstate новее, чем -m state и --state

И помимо политики, ваши правила будут

iptables -A INPUT -p tcp -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT 

iptables -A INPUT -p tcp -m multiport --sports 80,443 -j ACCEPT

Кроме того, тот стиль, который вы использовали и который я написал выше в соответствии с вашей формой, - это стиль командной строки, но некоторые могут сказать, что более профессионально использовать скрипт iptables. и строка будет читать -A input, а не iptables -A input. И файл iptables-save> и файл iptables-restore <файл.

|источник
0

Вам действительно нужно 2 правила для обработки портов 80 и 443, т.е. HTTP; трафик всегда переносится на порт 80, но вам нужно 2 правила ... Первое правило позволяет отправлять запрос на удаленную страницу ... Второе правило позволяет ответу на этот запрос (отправленный целевым HTTP-сервером) вернуться в ваш браузер.

Это правила

iptables -A OUTPUT -o eth0 -p tcp -m multiport --dports 80,443 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp -m multiport --sports 80,443 -m state --state RELATED,ESTABLISHED -j ACCEPT

и вы должны стереть это правило

iptables -A INPUT -i eth0 -p tcp -m multiport --dports 80,443 -j ACCEPT
|источник
0

Также требуется: 

iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT

И правило для ответов DNS должно быть ограничено фактическими ответами:

iptables -A INPUT -p udp -i eth0 --sport 53 -m state --state ESTABLISHED -j ACCEPT
|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .