<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
	<channel>
		<title>Mikrotik.moscow [тема: Переадресация TCP 80 для веб-сервера (насколько важны TCP-флаги)]</title>
		<link>http://mikrotik.moscow</link>
		<description>Новое в теме Переадресация TCP 80 для веб-сервера (насколько важны TCP-флаги) форума RouterOS на сайте Mikrotik.moscow [mikrotik.moscow]</description>
		<language>ru</language>
		<docs>http://backend.userland.com/rss2</docs>
		<pubDate>Thu, 13 Aug 2026 19:40:10 -0400</pubDate>
		<item>
			<title>Переадресация TCP 80 для веб-сервера (насколько важны TCP-флаги)</title>
			<description><![CDATA[<b><a href="http://mikrotik.moscow/forum/forum57/83550-pereadresatsiya-tcp-80-dlya-veb_servera-_naskolko-vazhny-tcp_flagi/message377709">Переадресация TCP 80 для веб-сервера (насколько важны TCP-флаги)</a></b> <i>RouterOS</i> в форуме <a href="http://mikrotik.moscow/forum/forum57/">RouterOS</a>. <br />
			У кого-нибудь есть идеи, как входящие подключения можно сделать более безопасными, проверяя TCP-флаги? <br />
			<i>08.03.2016 19:51:00, onlineuser.</i>]]></description>
			<link>http://mikrotik.moscow/forum/forum57/83550-pereadresatsiya-tcp-80-dlya-veb_servera-_naskolko-vazhny-tcp_flagi/message377709</link>
			<guid>http://mikrotik.moscow/forum/forum57/83550-pereadresatsiya-tcp-80-dlya-veb_servera-_naskolko-vazhny-tcp_flagi/message377709</guid>
			<pubDate>Tue, 08 Mar 2016 19:51:00 -0500</pubDate>
			<category>RouterOS</category>
		</item>
		<item>
			<title>Переадресация TCP 80 для веб-сервера (насколько важны TCP-флаги)</title>
			<description><![CDATA[<b><a href="http://mikrotik.moscow/forum/forum57/83550-pereadresatsiya-tcp-80-dlya-veb_servera-_naskolko-vazhny-tcp_flagi/message377708">Переадресация TCP 80 для веб-сервера (насколько важны TCP-флаги)</a></b> <i>RouterOS</i> в форуме <a href="http://mikrotik.moscow/forum/forum57/">RouterOS</a>. <br />
			никто? <br />
			<i>22.01.2016 14:16:00, onlineuser.</i>]]></description>
			<link>http://mikrotik.moscow/forum/forum57/83550-pereadresatsiya-tcp-80-dlya-veb_servera-_naskolko-vazhny-tcp_flagi/message377708</link>
			<guid>http://mikrotik.moscow/forum/forum57/83550-pereadresatsiya-tcp-80-dlya-veb_servera-_naskolko-vazhny-tcp_flagi/message377708</guid>
			<pubDate>Fri, 22 Jan 2016 14:16:00 -0500</pubDate>
			<category>RouterOS</category>
		</item>
		<item>
			<title>Переадресация TCP 80 для веб-сервера (насколько важны TCP-флаги)</title>
			<description><![CDATA[<b><a href="http://mikrotik.moscow/forum/forum57/83550-pereadresatsiya-tcp-80-dlya-veb_servera-_naskolko-vazhny-tcp_flagi/message377707">Переадресация TCP 80 для веб-сервера (насколько важны TCP-флаги)</a></b> <i>RouterOS</i> в форуме <a href="http://mikrotik.moscow/forum/forum57/">RouterOS</a>. <br />
			Спасибо. Да, возможны разные комбинации, но если я разрешу только «хорошие» сочетания для переадресации порта 80 и отклоню все остальные, то должно работать. Я пытался настроить на входящем порту 80 правило с флагами syn и ack, чтобы проверить правильность рукопожатия, но это не сработало. К тому же, логи Mikrotik не очень подробные — было бы отлично, если бы в них также фиксировались номера последовательностей и так далее.<br /><br />Обычно правильный порядок такой: входящие — 1 syn, 3 psh+ack; исходящие — 2 syn-ack. Сейчас я создал три правила, но как сделать так, чтобы соблюдался именно этот порядок? Любой другой порядок, например ack, syn, psh+ack, был бы недопустим. Как настроить, чтобы правило 3 срабатывало только если перед этим прошло правило 1? <br />
			<i>06.01.2016 09:58:00, onlineuser.</i>]]></description>
			<link>http://mikrotik.moscow/forum/forum57/83550-pereadresatsiya-tcp-80-dlya-veb_servera-_naskolko-vazhny-tcp_flagi/message377707</link>
			<guid>http://mikrotik.moscow/forum/forum57/83550-pereadresatsiya-tcp-80-dlya-veb_servera-_naskolko-vazhny-tcp_flagi/message377707</guid>
			<pubDate>Wed, 06 Jan 2016 09:58:00 -0500</pubDate>
			<category>RouterOS</category>
		</item>
		<item>
			<title>Переадресация TCP 80 для веб-сервера (насколько важны TCP-флаги)</title>
			<description><![CDATA[<b><a href="http://mikrotik.moscow/forum/forum57/83550-pereadresatsiya-tcp-80-dlya-veb_servera-_naskolko-vazhny-tcp_flagi/message377706">Переадресация TCP 80 для веб-сервера (насколько важны TCP-флаги)</a></b> <i>RouterOS</i> в форуме <a href="http://mikrotik.moscow/forum/forum57/">RouterOS</a>. <br />
			Раньше у меня было несколько правил, которые проверяли TCP-флаги, но потом я понял, что это всё равно что просверлить ещё одну дырку в крышке мусорного ведра, так сказать… Я и так собирался выбросить всё ненужное, а Mikrotik уже настроен так, чтобы блокировать все подключения с WAN, кроме статического IP моего офиса. Тем более, способов поиграться с TCP-флагами гораздо больше, чем я знаю, и ещё появятся новые в будущем. Если уж очень хочется, я бы просто изменил правило, разрешающее tcp/80 со статусом new, чтобы требовать установки флага syn. Что касается таймаутов в отслеживании соединений, мне в большинстве случаев подходят стандартные настройки таймеров для TCP. <br />
			<i>04.01.2016 21:08:00, ZeroByte.</i>]]></description>
			<link>http://mikrotik.moscow/forum/forum57/83550-pereadresatsiya-tcp-80-dlya-veb_servera-_naskolko-vazhny-tcp_flagi/message377706</link>
			<guid>http://mikrotik.moscow/forum/forum57/83550-pereadresatsiya-tcp-80-dlya-veb_servera-_naskolko-vazhny-tcp_flagi/message377706</guid>
			<pubDate>Mon, 04 Jan 2016 21:08:00 -0500</pubDate>
			<category>RouterOS</category>
		</item>
		<item>
			<title>Переадресация TCP 80 для веб-сервера (насколько важны TCP-флаги)</title>
			<description><![CDATA[<b><a href="http://mikrotik.moscow/forum/forum57/83550-pereadresatsiya-tcp-80-dlya-veb_servera-_naskolko-vazhny-tcp_flagi/message377705">Переадресация TCP 80 для веб-сервера (насколько важны TCP-флаги)</a></b> <i>RouterOS</i> в форуме <a href="http://mikrotik.moscow/forum/forum57/">RouterOS</a>. <br />
			Ок, большое спасибо. Все ваши советы я уже внедрил. У моего RB2011 загрузка процессора примерно от 3 до 15 процентов (около 30-40 постоянных исходящих/входящих соединений). Поэтому я подумал, что роутер мог бы также проверять трафик на наличие аномалий, например: инициацию, трехстороннее рукопожатие, правильную синхронизацию и подтверждение и так далее. Меня интересует, был ли случай каких-то тестов на проникновение или хакерских атак, где в первой инстанции участвовал именно роутер Mikrotik? <br />
			<i>04.01.2016 20:46:00, onlineuser.</i>]]></description>
			<link>http://mikrotik.moscow/forum/forum57/83550-pereadresatsiya-tcp-80-dlya-veb_servera-_naskolko-vazhny-tcp_flagi/message377705</link>
			<guid>http://mikrotik.moscow/forum/forum57/83550-pereadresatsiya-tcp-80-dlya-veb_servera-_naskolko-vazhny-tcp_flagi/message377705</guid>
			<pubDate>Mon, 04 Jan 2016 20:46:00 -0500</pubDate>
			<category>RouterOS</category>
		</item>
		<item>
			<title>Переадресация TCP 80 для веб-сервера (насколько важны TCP-флаги)</title>
			<description><![CDATA[<b><a href="http://mikrotik.moscow/forum/forum57/83550-pereadresatsiya-tcp-80-dlya-veb_servera-_naskolko-vazhny-tcp_flagi/message377704">Переадресация TCP 80 для веб-сервера (насколько важны TCP-флаги)</a></b> <i>RouterOS</i> в форуме <a href="http://mikrotik.moscow/forum/forum57/">RouterOS</a>. <br />
			Лично я считаю, что это излишне для роутеров — убедитесь, что ОС сервера и приложения, доступные из интернета, всегда вовремя обновляются и поддерживаются в актуальном состоянии с последними патчами. Конечно, у хакеров найдётся больше способов взломать систему, чем вы сможете придумать с помощью странных комбинаций TCP-флагов и разных таймаутов.<br /><br />Следуйте лучшим практикам: если функция не нужна — отключите её. Если нужна — включите и держите в актуальном состоянии.<br /><br />По поводу фаерволов: перенаправляйте только пакеты для тех сервисов, которые собираетесь предоставлять, а все остальные соединения сбрасывайте.<br /><br />Если хотите обнаруживать сканирование портов и временно добавлять источники в чёрный список:<br />- первые два правила фильтра должны быть drop для src-address-list=BLACKLIST и dst-address-list=BLACKLIST<br />- правила, разрешающие доступ к вашим сервисам (например, разрешить входящий http), настройте с ограничением скорости по src-адресу<br />- такое же ограничение скорости поставьте на правило “отбрасывать все остальные” (тоже по src-адресу)<br />- затем добавьте правило, которое помещает src-адрес в BLACKLIST с timeout=1d (или на любое другое нужное время)<br />- и в конце правило drop без ограничений<br /><br />Возможно, стоит создать ещё один список адресов ‘UNBANNABLE’ и изменить правило добавления в BLACKLIST с условием src-address-list=!UNBANNABLE. Это не позволит злоумышленникам подделывать важные удалённые адреса своими действиями, которые могли бы привести к их блокировке (например, корневые DNS-серверы).<br /><br />Также можно настроить «стук по портам» (port knock), чтобы внутренние серверы могли сами добавлять IP в чёрный список при срабатывании fail2ban... То есть, если сервер зафиксирует попытку взлома ssh грубой силой, он забанит IP для своих сервисов, а потом отправит «стук» на Mikrotik, и тот добавит этот IP в чёрный список. <br />
			<i>04.01.2016 16:19:00, ZeroByte.</i>]]></description>
			<link>http://mikrotik.moscow/forum/forum57/83550-pereadresatsiya-tcp-80-dlya-veb_servera-_naskolko-vazhny-tcp_flagi/message377704</link>
			<guid>http://mikrotik.moscow/forum/forum57/83550-pereadresatsiya-tcp-80-dlya-veb_servera-_naskolko-vazhny-tcp_flagi/message377704</guid>
			<pubDate>Mon, 04 Jan 2016 16:19:00 -0500</pubDate>
			<category>RouterOS</category>
		</item>
		<item>
			<title>Переадресация TCP 80 для веб-сервера (насколько важны TCP-флаги)</title>
			<description><![CDATA[<b><a href="http://mikrotik.moscow/forum/forum57/83550-pereadresatsiya-tcp-80-dlya-veb_servera-_naskolko-vazhny-tcp_flagi/message377703">Переадресация TCP 80 для веб-сервера (насколько важны TCP-флаги)</a></b> <i>RouterOS</i> в форуме <a href="http://mikrotik.moscow/forum/forum57/">RouterOS</a>. <br />
			Как можно настроить список fail2ban для IP-адресов, которые пытаются использовать несколько неправильных комбинаций tcp-флагов? Возможно ли обнаруживать и фильтровать такие подозрительные запросы? <br />
			<i>04.01.2016 16:01:00, onlineuser.</i>]]></description>
			<link>http://mikrotik.moscow/forum/forum57/83550-pereadresatsiya-tcp-80-dlya-veb_servera-_naskolko-vazhny-tcp_flagi/message377703</link>
			<guid>http://mikrotik.moscow/forum/forum57/83550-pereadresatsiya-tcp-80-dlya-veb_servera-_naskolko-vazhny-tcp_flagi/message377703</guid>
			<pubDate>Mon, 04 Jan 2016 16:01:00 -0500</pubDate>
			<category>RouterOS</category>
		</item>
		<item>
			<title>Переадресация TCP 80 для веб-сервера (насколько важны TCP-флаги)</title>
			<description><![CDATA[<b><a href="http://mikrotik.moscow/forum/forum57/83550-pereadresatsiya-tcp-80-dlya-veb_servera-_naskolko-vazhny-tcp_flagi/message377702">Переадресация TCP 80 для веб-сервера (насколько важны TCP-флаги)</a></b> <i>RouterOS</i> в форуме <a href="http://mikrotik.moscow/forum/forum57/">RouterOS</a>. <br />
			Я настроил переадресацию порта 80 на свою DMZ. Насколько важно при этом указывать TCP-флаги ACK, SYN, PSH, FIN в правилах фаервола? Сначала нужен dst-nat, потом правило с WAN в DMZ, и еще одно — с DMZ в WAN. Как правильно выставить TCP-флаги в этих двух правилах, чтобы маршрутизация была безопасной? Заметил, что TCP-сессии с веб-сервером держатся очень долго — можно ли уменьшить таймаут? Сейчас с одного IP-адреса из Китая пришло много подозрительных запросов. Как настроить fail2ban для IP, которые пытаются несколько неправильных комбинаций TCP-флагов? <br />
			<i>23.10.2015 20:49:00, onlineuser.</i>]]></description>
			<link>http://mikrotik.moscow/forum/forum57/83550-pereadresatsiya-tcp-80-dlya-veb_servera-_naskolko-vazhny-tcp_flagi/message377702</link>
			<guid>http://mikrotik.moscow/forum/forum57/83550-pereadresatsiya-tcp-80-dlya-veb_servera-_naskolko-vazhny-tcp_flagi/message377702</guid>
			<pubDate>Fri, 23 Oct 2015 20:49:00 -0400</pubDate>
			<category>RouterOS</category>
		</item>
	</channel>
</rss>
