Вопросы Теги

Марсианские источники с моего общедоступного IP

В последнее время я получаю несколько марсианских пакетов в kern.log: 

Jul  7 02:28:20 box14932 kernel: [789192.798073] IPv4: martian source XXX.XXX.XXX.XXX from 10.91.12.01, on dev eth1
Jul  7 02:28:20 box14932 kernel: [789192.798095] ll header: 00000000: 44 a8 12 41 1d 2b 13 8b 9c ab 34 89 10 00        D.BB.......Y..
Jul  7 04:29:12 box14932 kernel: [798267.423393] IPv4: martian source XXX.XXX.XXX.XXX from 10.91.20.10, on dev eth1
Jul  7 04:29:12 box14932 kernel: [798267.423401] ll header: 00000000: 44 a8 12 41 1d 2b 13 8b 9c ab 34 89 10 00        D.BB.......Y..
Jul  7 04:29:12 box14932 kernel: [798267.423408] IPv4: martian source XXX.XXX.XXX.XXX from 10.91.20.10, on dev eth1
Jul  7 04:29:12 box14932 kernel: [798267.423410] ll header: 00000000: 44 a8 12 41 1d 2b 13 8b 9c ab 34 89 10 00        D.BB.......Y..

Источник «XXX.XXX.XXX.XXX» - это общедоступный IP-адрес моего сервера.

Я ищу в гугле, толком не нашел, что это было. Это спуфинговая атака или просто проблема с сетевой конфигурацией на моем сервере?

У меня есть два интерфейса на моем сервере:

  • eth1 - это основной интерфейс (общедоступный IP)
  • eth2 - это Интерфейс RPN (настоящая частная сеть, поэтому не подключен к общедоступной сети), чей IP-адрес начинается с 10.91 ...
  • lo , что, очевидно, является обратной связью.

Вот моя конфигурация sysctl.conf, где rp_filter = 1 и log_martians = 1: 

# Log Martians
net.ipv4.conf.all.log_martians = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1


# IP Spoofing protection
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Disable source packet routing
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0 
net.ipv4.conf.default.accept_source_route = 0
net.ipv6.conf.default.accept_source_route = 0

# Ignore send redirects
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0

# Block SYN attacks
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 5

# Ignore ICMP redirects
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0 
net.ipv6.conf.default.accept_redirects = 0

Кто-нибудь может мне помочь? Стоит ли мне беспокоиться об этих марсианах?

Что вы скажете о добавлении правил iptables для DROP и LOG пакетов, например: удобный способ сохранить удобство использования scp и переадресации портов без ослабления ограничений безопасности?

Большое спасибо за вашу помощь!

0
задан 13 April 2017 в 15:14
1 ответ

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

Но вы можете организовать все так, чтобы закрытые ключи могли только можно использовать из окна перехода (см. man sshd , from = в ФОРМАТЕ ФАЙЛА AUTHORIZED_KEYS). Затем, отказ определенного администратора в доступе к Jumpbox, оставляет ему или ей ключи, которые больше не используются.

Удовлетворяет ли это вашим ограничениям безопасности?

Обратите внимание, что вы пишете так, как будто все удаленные администраторы имеют доступ к общей учетной записи. на джампбоксе. Если бы это была моя система, я бы этого не сделал; Я бы хотел, чтобы у каждого удаленного администратора была отдельная учетная запись на jumpbox, причем все такие учетные записи имели доступ к соответствующей дополнительной паре ключей или ее копии. Это делает отмену доступа отдельного администратора к Jumpbox намного проще и надежнее.

3
ответ дан 4 December 2019 в 12:23

Теги

Похожие вопросы