Как отключить icmp linux

Как отключить/включить ответ ping в Linux

Главное меню » Linux » Как отключить/включить ответ ping в Linux

1 Отключить/включить постоянный ответ ping (через sysctl)

1.1 Добавьте следующую строку в «/etc/sysctl.conf» (чтобы включить, измените 1 на 0)

Мы можем использовать следующую команду для достижения этого

1.2 Применить изменение

2 Временно отключить/включить ответ ping (через sysctl)

2.1 Выполните следующую команду, чтобы временно отключить ответ ping (чтобы включить, измените 1 на 0)

2.2 Применить изменение

3 Временно отключить ответ ping (через брандмауэр/iptables)

3.1 Выполните следующую команду, чтобы заблокировать/сбросить ping-трафик

Примечание. Хотя правила iptables будут действовать после перезагрузки в CentOS и RHEL, они не будут действовать после перезагрузки в Debian/Ubuntu/Kali Linux и т. д..

4 Временно включить ответ ping (через брандмауэр/iptables)

4.1 Выполните следующую команду, чтобы включить/разрешить ping-трафик

Примечание. Как и в разделе 3, правила firewall/iptables будут действовать после перезагрузки в CentOS и RHEL, они не будут действовать после перезагрузки в Debian/Ubuntu/Kali Linux и т. д.

Бонус

Еще один способ легко разрешить ответ ping – просто временно отключить iptables/firewall.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник

Настройка ядра Linux для тяжелых проектов и защиты от DDOS

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

Сейчас речь пойдет о том, как можно настроить ядро Linux сервера, чтобы он смог переваривать большое количество запросов, а так же DDos. Все будет кратко с небольшим описанием.

Много материалов я вычитал, для того чтобы понять какие значения оптимальны, так же прилично всего перепробовал, и некоторые решения помогли мне уйти от той высокой нагрузки на сервере. Так же грамотная настройка ядра сервера позволит вам защититься от SYN flood. Ладно, начнем..

Каждый параметр подробненько…

rp_filter

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

По умолчанию он отключен:

Рекомендуется включить в «строгий режим» проверки (значение 2 включает «свободный режим» проверки), причем включить его можно на всех интерфейсах:

Так проверку можно включить на определенном интерфейсе:

accept_source_route

— запрет маршрутизации от источников.

По умолчанию эта опция отключена:

Но если она у вас почему-то включена — отключите, желательно на всех интерфейсах:

accept_redirects, secure_redirects, send_redirects

— этими тремя параметрами мы запрещаем принимать и отправлять ICMP пакеты перенаправления. ICMP-перенаправления могут быть использованы злоумышленником для изменения таблиц маршрутизации.

secure_redirects — BOOLEAN
Accept ICMP redirect messages only to gateways listed in the
interface’s current gateway list. Even if disabled, RFC1122 redirect
rules still apply.
Overridden by shared_media.
secure_redirects for the interface will be enabled if at least one of
conf//secure_redirects is set to TRUE,
it will be disabled otherwise
default TRUE

send_redirects — BOOLEAN
Send redirects, if router.
send_redirects for the interface will be enabled if at least one of
conf//send_redirects is set to TRUE,
it will be disabled otherwise
Default: TRUE

По умолчанию все эти параметры включены:

Но, так как наш сервер не маршрутизатор, в них нет необходимости:

icmp_echo_ignore_broadcasts

— отключаем ответ на ICMP ECHO запросы, переданные широковещательными пакетами.

По умолчанию включено, т.е. broadcast icmp запросы приходить не будут:

Так и рекомендуется отставить:

icmp_ignore_bogus_error_responses

— игнорируем ошибочные ICMP запросы.

Так и рекомендуется отставить:

icmp_echo_ignore_all

— отключаем ответ на ICMP запросы (сервер не будет пинговаться)

На ваше усмотрение, можно отключить:

tcp_syncookies

— по умолчанию данный параметр обычно включен. Если количество SYN пакетов забивает всю очередь, включается механизм Syn cookies.

Как проверить, включен ли он у нас:

Если выдает 1, то включен, 0 — значит отключен. Для отключения «на лету» достаточно воспользоваться следующей командой:

Естественно поставив в конце «1» — механизм будет снова включен.

Если параметр tcp_syncookies установлен (доступен только когда ядро собрано с CONFIG_SYNCOOKIES), тогда ядро обрабатывает SYN пакеты TCP в обычном режиме до тех пор, пока очередь не заполнится. После заполнения очереди включается механизм SYN cookies.

SYN cookies вообще не использует очередь SYN. Вместо этого ядро отвечает на каждый SYN пакет, как обычно SYN|ACK, но туда будет включено специально сгенерированное число на основе IP адресов и портов источника и получателя, а также времени посылки пакета. Атакующий никогда не получит эти пакеты, а поэтому и не ответит на них. При нормальном соединении, будет послан третий пакет, содержащий число, а сервер проверит был ли это ответ на SYN cookie и, если да, то разрешит соединение даже в том случае, если в очереди SYN нет соответствующей записи.

Включение механизма SYN cookies является очень простым способом борьбы против атаки SYN флудом. При этом немного больше загружается процессор из-за необходимости создавать и сверять cookie. Так как альтернативным решением является отклонять все запросы на соединение, SYN cookies являются хорошим выбором.

Таким образом, как описано выше, мы получаем неплохую защиту от syn флуда и терпим небольшую нагрузку на ЦП..

Но согласно описанию, включать генерацию syncookies на высоконагруженных серверах, для которых этот механизм срабатывает, при большом количестве легальных соединений, не следует. Если в логах есть предупреждения о SYN-флуде, при этом это вполне нормальные соединения, нужно настраивать другие параметры: tcp_max_syn_backlog, tcp_synack_retries, tcp_abort_on_overflow.

tcp_max_syn_backlog

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

Если на сервере возникают перегрузки, можно попытаться увеличить это значение, например до 4096:

tcp_synack_retries

— время удержания «полуоткрытых» соединений.

Это значение имеет смысл уменьшить, например до 1 (это будет 9 секунд):

tcp_max_orphans

— определяет максимальное число «осиротевших» TCP пакетов.

Рекомендуется установить 65536, а далее увеличивать, по мере необходимости:

tcp_fin_timeout

— время ожидания приема FIN до полного закрытия сокета.

Рекомендуется поменять на 10 секунд:

tcp_keepalive_time

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

По умолчанию 2 часа:

Рекомендуется каждую минуту:

tcp_keepalive_intvl

— интервал подачи проб…

tcp_keepalive_probes

— Количество проверок перед закрытием соединения.

netdev_max_backlog

— Параметр определяет максимальное количество пакетов в очереди на обработку, если интерфейс получает пакеты быстрее, чем ядро может их обработать.

Рекомендуется так и оставить:

somaxconn

— Максимальное число открытых сокетов, ждущих соединения.

Рекомендуется установить значения в районе 15000-20000:

tcp_mem

— векторная (минимум, режим нагрузки, максимум) переменная которая cодержит общие настройки потребления памяти для протокола TCP

Можно поставить эти же значения.увеличивать имеет смысл в случае увеличения нагрузки.

tcp_rmem

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

Можно поставить эти же значения.увеличивать имеет смысл в случае увеличения нагрузки. В одном из источнике рекомендовали следующие значения:

tcp_wmem

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

Можно оставить эти же значения. Увеличивать их имеет смысл в случае увеличения нагрузки. В одном из источнике рекомендовали следующие значения:

rmem_default, wmem_default

Так же есть «глобальные» параметры размеров буфера, и они не перекрывают значения переменных tcp_rmem и tcp_wmem (читай описание выше)

• rmem_default — размер буфера приема данных по умолчанию для всех соединений.
• wmem_default — Размер буфера передачи данных по умолчанию для всех соединений.

Их значения по умолчанию:

Можно оставить эти же значения. Увеличивать их имеет смысл в случае увеличения нагрузки. Например, в одном из источнике рекомендовали следующие значения:

rmem_max, wmem_max

а эти «глобальные» параметры перекрывают «максимумы» переменных tcp_rmem и tcp_wmem (опять же, читай описание выше)

• rmem_max — максимальный размер буфера приема данных для всех соединений.
• wmem_max — максимальный размер буфера передачи данных для всех соединений.

Их значения по умолчанию:

Можно оставить эти же значения. Увеличивать их имеет смысл в случае увеличения нагрузки. Например, в одном из источнике рекомендовали следующие значения:

tcp_orphan_retries

— параметр который определяет число неудачных попыток, после которого уничтожается соединение TCP, закрытое на локальной стороне.

Рекомендуется уменьшить значение этого параметра, поскольку закрытые соединения могут поглощать достаточно много ресурсов (т.е. оставляем 0):

ip_conntrack_max

— Максимальное количество соединений для работы механизма connection tracking (используется, например, iptables).

При слишком маленьких значениях ядро начинает отвергать входящие подключения с соответствующей записью в системном логе:

tcp_timestamps

— включает временные метки протокола TCP, которые позволяют управлять работой протокола в условиях высоких нагрузок (с помощью tcp_congestion_control)

По умолчанию метки включены:

Кстати, лучше отставить его включенным, иначе не будет работать опция tcp_tw_reuse.

tcp_sack

— разрешаем выборочные подтверждения протокола TCP. Опция необходима для эффективного использования всей доступной пропускной способности некоторых сетей.

По умолчанию опция включена:

Рекомендуется включать эту опцию, если вы имеете неустойчивые соединения. Однако, если вы соединены 1.5-метровым кабелем с другой машиной, то в таком случае, для достижения наивысшей скорости обмена, следует эту опцию отключить:

tcp_congestion_control

— протокол, используемый для управления нагрузкой в сетях TCP. bic и cubic реализации, используемые по умолчанию, содержат баги в большинстве версий ядра RedHat и ее клонов. Рекомендуется использовать htcp.

Для сервера рекомендуется использовать htcp:

tcp_no_metrics_save

— данная опция запрещает сохранять результаты изменений TCP соединения в кеше при его закрытии.

По умолчанию опция ничего не запрещает:

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

net.ipv4.route.flush

— актуально для ядер 2.4. По странной причине в ядрах 2.4, если в рамках TCP сессии произошел повтор передачи с уменьшенным размером окна, все соединения с данным хостом в следующие 10 минут будут иметь именно этот уменьшенный размер окна. Данная настройка позволяет этого избежать.

Так как в ядре 3.2 она даже не читается, менять ничего не стал.

ip_local_port_range

— опция, которая содержит диапазон локальных портов, доступных для установки исходящих подключений.

По умолчанию там такой диапазон:

Для тяжелых проектов диапазон рекомендуется увеличить:

tcp_tw_reuse

— опция позволяющая повторное использование TIME-WAIT сокетов в случаях, если протокол считает это безопасным.

По умолчанию отключена:

tcp_window_scaling

— опция позволяет динамически изменять размер окна TCP стека

По умолчанию она включена:

Лучше так и оставить:

tcp_rfc1337

— с помощью этой опции мы можем защитить себя от TIME_WAIT атак.

По умолчанию опция отключена:

На сервере она точно не помешает:

ip_forward

— данная опция управляет переадресацией пакетов. Если этот параметр выключен, ОС считает себя узлом IP сети и дропает все пакеты, предназначенные не ей. Если параметр включен, то ОС считает себя маршрутизатором и действует в соответствии с RFC1812, в том числе пытается переслать адресованные не ей пакеты в соответствии с таблицей маршрутизации.

По умолчанию переадресация включена:

Если сервер не является маршрутизатором, то включать эту опцию нет необходимости:

tcp_abort_on_overflow

— Эта переменная заставляет ядро отвергать новые соединения, если их поступает количество, с которым система не в состоянии справиться. Эту переменную следует использовать как крайнюю меру! По умолчанию она отключена:

Если ситуация требует, то ее можно включить:

Как все это применить?

Я намеренно для изменения параметров использовал утилиту sysctl, а значения этих параметров просто читал с помощью cat. Сделано это было все для того, чтобы вам было ясно что способов изменения параметров ядра много.

Например, внести изменения мы так же можем с помощью echo:

А прочитать значения мы так же можем с помощью команды sysctl:

Кому какой способ больше нравится — решайте сами.

Как применить все эти значения разом, не сохраняя их?

Можно прочитать все описание выше и каждую переменную применять руками, с помощью «sysctl -w», и все эти значения будут работать до тех пор, пока вы не перезагрузите систему. Это полезно, пока ваше ядро находится в режиме «вашей отладки».

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

Как сохранить эти значения?

Если сервер работает корректно со всеми настройками указанными выше, то для их сохранения достаточно добавить все эти переменные в конец файла /etc/sysctl.conf:

Заключение

На этом вроде все. В процессе написания статьи я изучал всевозможные настройки ядра, поэтому если есть где-то неточности или вам есть чем дополнить данный материал — пишите, буду очень рад.

Источник