У меня есть корневой доступ 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
все еще доступный.
Возможно, у хостинг-провайдера есть служба межсетевого экрана, по умолчанию разрешающая только ssh-трафик на сервер. Цель такого значения по умолчанию может заключаться в ограничении уязвимости сервера до тех пор, пока у вас не будет времени для установки всех обновлений безопасности, усилении вашей конфигурации и в целом обеспечении готовности вашего сервера к запуску.
Если такая служба произойдет с на месте, скорее всего, будет существовать веб-интерфейс, через который его можно будет настроить. Также должно быть место, чтобы полностью отключить его.
Я бы порекомендовал следующие шаги:
Что вы можете сделать, чтобы сузить местоположение фильтров, так это использовать traceroute
команда. В Ubuntu 14.04 есть команда traceroute
с флагами, которые могут отправлять пакеты с определенным протоколом и номером порта. Таким образом вы можете, например, сравнить выходные данные, полученные от трассировки, с портом 22 и портом 80.
traceroute -n -T -p 22 server
Обратите внимание, что существуют разные реализации traceroute
. Если по какой-то причине кажется, что флаги не работают, попробуйте traceroute.db
, который даст вам версию с поддержкой указанной выше комбинации флагов.
По-видимому, в Linux нет другого брандмауэра, который бы фактически не использовал iptables / netfilter
. Также простой SYN-тест - это правильный способ проверить, фильтруется ли ваш трафик брандмауэром. Вы правы в том, что поиск «восходящего» брандмауэра, группы безопасности этого экземпляра EC2 в этом примере, является единственным разумным способом решить эту проблему. Спасибо за ваш вклад, который привел к этому ответу.