Как обнаружить то, что блокирует мой входящий трафик на Ubuntu 14.04 LTS, если это не iptables и НЕ Группа безопасности EC2?

У меня есть корневой доступ SSH к экземпляру EC2.

Это - Ubuntu 14.04 LTS.

Я имею nginx веб-сервер, слушающий во всех интерфейсах на порте 80 TCP. Это доступно с этого сервера, но не с внешней стороны.

По-видимому, весь мой входящий трафик кроме 22 TCP заблокирован - другие порты TCP, весь UDP и ICMP.

Все же мой iptables на этом сервере пусты:

root@ip-x-x-x-x:~# iptables -v -L
Chain INPUT (policy ACCEPT 3162 packets, 1472K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 4203 packets, 674K bytes)
 pkts bytes target     prot opt in     out     source               destination  

Вот nmap сканирование произвело от моей локальной машины:

grzegorz@MacBook-Pro-Grzegorz:~$ sudo nmap -v -Pn -p 22,80 x.x.x.x

Starting Nmap 6.47 ( http://nmap.org ) at 2015-01-31 20:40 CET
Initiating Parallel DNS resolution of 1 host. at 20:40
Completed Parallel DNS resolution of 1 host. at 20:40, 0.16s elapsed
Initiating SYN Stealth Scan at 20:40
Scanning ec2-x-x-x-x.eu-central-1.compute.amazonaws.com (x.x.x.x) [2 ports]
Discovered open port 22/tcp on 54.93.91.112
Completed SYN Stealth Scan at 20:40, 1.38s elapsed (2 total ports)
Nmap scan report for ec2-x-x-x-x.eu-central-1.compute.amazonaws.com (x.x.x.x)
Host is up (0.035s latency).
PORT   STATE    SERVICE
22/tcp open     ssh
80/tcp filtered http

Read data files from: /usr/local/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 1.58 seconds
           Raw packets sent: 3 (132B) | Rcvd: 1 (44B)

.. таким образом, некоторый брандмауэр блокирует мой трафик.

Давайте предположим, что это не Группа безопасности EC2.

Что еще может блокировать мой трафик? Что-то, что работает на самом VPS? Что-то в ядре или что-то в пространстве пользователя?


ОБНОВЛЕНИЕ:

Я протестировал apparmor:

root@ip-x-x-x-x:~# apparmor_status --verbose
apparmor module is loaded.
4 profiles are loaded.
4 profiles are in enforce mode.
   /sbin/dhclient
   /usr/lib/NetworkManager/nm-dhcp-client.action
   /usr/lib/connman/scripts/dhclient-script
   /usr/sbin/tcpdump
0 profiles are in complain mode.
1 processes have profiles defined.
1 processes are in enforce mode.
   /sbin/dhclient (607) 
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

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

root@ip-x-x-x-x:~# service apparmor stop
 * Clearing AppArmor profiles cache
   ...done.
All profile caches have been cleared, but no profiles have been unloaded.
Unloading profiles will leave already running processes permanently
unconfined, which can lead to unexpected situations.

To set a process to complain mode, use the command line tool
'aa-complain'. To really tear down all profiles, run the init script
with the 'teardown' option."
root@ip-x-x-x-x:~# service apparmor teardown
 * Unloading AppArmor profiles
   ...done.

.. но это не помогло. nmap все еще шоу filtered TCP 80, nginx все еще доступный.

0
задан 31 January 2015 в 22:14
2 ответа

Возможно, у хостинг-провайдера есть служба межсетевого экрана, по умолчанию разрешающая только ssh-трафик на сервер. Цель такого значения по умолчанию может заключаться в ограничении уязвимости сервера до тех пор, пока у вас не будет времени для установки всех обновлений безопасности, усилении вашей конфигурации и в целом обеспечении готовности вашего сервера к запуску.

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

Я бы порекомендовал следующие шаги:

  1. Прочтите документацию хостинг-провайдера, чтобы узнать, работает ли служба межсетевого экрана, подобная описанной выше.
  2. Используйте инструменты, чтобы сузить местоположение любых фильтров, для которых вы не нашли документации.
  3. Спросите поставщика

Что вы можете сделать, чтобы сузить местоположение фильтров, так это использовать traceroute команда. В Ubuntu 14.04 есть команда traceroute с флагами, которые могут отправлять пакеты с определенным протоколом и номером порта. Таким образом вы можете, например, сравнить выходные данные, полученные от трассировки, с портом 22 и портом 80.

traceroute -n -T -p 22 server

Обратите внимание, что существуют разные реализации traceroute . Если по какой-то причине кажется, что флаги не работают, попробуйте traceroute.db , который даст вам версию с поддержкой указанной выше комбинации флагов.

1
ответ дан 4 December 2019 в 17:04

По-видимому, в Linux нет другого брандмауэра, который бы фактически не использовал iptables / netfilter . Также простой SYN-тест - это правильный способ проверить, фильтруется ли ваш трафик брандмауэром. Вы правы в том, что поиск «восходящего» брандмауэра, группы безопасности этого экземпляра EC2 в этом примере, является единственным разумным способом решить эту проблему. Спасибо за ваш вклад, который привел к этому ответу.

0
ответ дан 4 December 2019 в 17:04

Теги

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