LINUX.ORG.RU
Форум — Admin  

Почему на CentOS может быть открыт порт 53?

 , ,


0

1

У меня сервер на CentOS. Сегодня проверил открытые порты через nmap. Среди прочих, открыт 53 порт.

На сервере несколько docker контейнеров.

firewall-cmd --list-all не показывает, что этот порт открыт.

Ладно, docker может отдельно от firewalld открывать порты. Проверяю, нигде в docker этот порт не открыт.

Вывод netstat -tunpl 

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      3024/sshd           
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      3676/master         
tcp6       0      0 :::80                   :::*                    LISTEN      13306/docker-proxy  
tcp6       0      0 :::22                   :::*                    LISTEN      3024/sshd           
tcp6       0      0 ::1:25                  :::*                    LISTEN      3676/master         
tcp6       0      0 :::443                  :::*                    LISTEN      13295/docker-proxy  
udp        0      0 127.0.0.1:323           0.0.0.0:*                           2439/chronyd        
udp6       0      0 ::1:323                 :::*                                2439/chronyd

22, 80 и 443 порт понятно. chronyd - это по идее время синхронизируется, хотя оно почему-то на localhost открыто. Master - это, наверное, Postfix, в CentOS 6 он по умолчанию локалхост слушал, в 7, может, это так же.

Вопрос почему наружу открыт 53 порт, а я не вижу его у себя в системе?

Все для чего использовалась система - это несколько контейнеров развернуть.


← Проблемы с именем хоста JITSI-MEET
KDE5/AlienBob/Slackware-14.2_x64 on VirtualBox →

53 это для DNS. Бинд там или днсмаск.

turtle_bazon ★★★★★
()

Ты точно машину напрямую nmap прошел?

kerneliq ★★★★★
()

А теперь мы все дружно должны догадаться.
1. Как у вас подключен хост? Голой попой в инет или через nat?
2. Откуда выхлоп «netstat -tunpl» из хоста/какого-то из докеров?
3. Поверить на слово, что nmap показал открытый порт
4. Поверить на слово «firewall-cmd....»

Отвечаем на вопросы, тогда возможно будет понятнее. И в части пункта 4, смотрим iptables-save

anc ★★★★★
()
Ответ на: комментарий от anc

1. В интернет подключен напрямую - это VPS.

2. выход netstat из хоста, ни в какой docker не заходил. Docker - это 80 и 443 порты, по netstat же видно.

3. nmap 

Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-20 08:22 MSK
Nmap scan report for адрес (айпи)
Host is up (0.59s latency).
rDNS record for адресъ
Not shown: 996 filtered ports
PORT    STATE SERVICE  VERSION
22/tcp  open  ssh      OpenSSH 7.4 (protocol 2.0)
53/tcp  open  domain   (unknown banner: dnsmasq-)
80/tcp  open  http
443/tcp open  ssl/http Golang net/http server (Go-IPFS json-rpc or InfluxDB API)

firewall-cmd 

public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources: 
  services: ssh dhcpv6-client
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules:

iptables-save

https://pastebin.com/i3kUA85Z

denko
() автор топика
Ответ на: комментарий от denko

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

infomeh ★★
()

Это сраный systemd открывает порты для своего dns! Так что тебе на последний годный серверный дистр без systemd - Ubuntu Server 14.04 LTS

menangen ★★★★★
()
Последнее исправление: menangen (всего исправлений: 1)
Ответ на: комментарий от infomeh

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

Блокирует же firewalld.

Проверил. Поставил netdata. На порт 19999 не смог попасть. Сделал firewall-cmd --add-port=19999/tcp netdata открылся. Перезагрузил сервер, порт опять закрыт. Все блокируется как нужно.

denko
() автор топика
Ответ на: комментарий от denko

Сразу попробуй

systemctl disable systemd-resolved

Да и 
53/tcp  open  domain   (unknown banner: dnsmasq-)

что навевает.
Что говорит 
ps ax|grep dnsmasq

hbars ★★★★★
()
Ответ на: комментарий от menangen

Это сраный systemd открывает порты для своего dns!

Нет, systemd так не делает.

Ubuntu Server 14.04 LTS

Бесплатная поддержка закончилась 30 апреля, если кто пропустил.

gremlin_the_red ★★★★★
()
Ответ на: комментарий от denko

Пакеты фильтрует пакетный фильтр в ядре Linux.

firewald - это лишь демон, который принимает команды на изменение правил пакетного фильтра. И он является лишь оболочкой (интерфейсом) над утилитами iptables, ebtables и прочего, т.е. в конечном счёте надо пакетным фильтром (netfilter) или его заменой в ядре.

Поставил netdata. На порт 19999 не смог попасть. С

Куда ты его поставил?

infomeh ★★
()
Ответ на: комментарий от denko

Очень детально каждую цепочку iptables не просмотрел, но имхо это похоже на происки провайдеров. Попробуйте запустить tcpdump на хосте и удаленно telnet || nc на 53-й порт подключиться. Долетают хоть пакеты до вас?

anc ★★★★★
()
Ответ на: комментарий от gremlin_the_red

Нет, systemd так не делает.

Таки делает. Выглядит это так (Ubuntu 18.04.2 LTS): 

udp        0      0 127.0.0.53:53           0.0.0.0:*                           6319/systemd-resolv
Но согласен, что к вопросу ТС это не имеет отношения. Возможно это проделки хостера, если ТС сканировал снаружи.

funky ★
()
Ответ на: комментарий от funky

Это не открытие порта. Это слушание порта на loopback-интерфейсе. Никакого правила netfilter при этом не добавляется.

gremlin_the_red ★★★★★
()
Ответ на: комментарий от infomeh

Куда ты его поставил?

Поставил на сервер, от которо iptables-save сюда выкладывал. На порт 19999 не смог попасть. Разрешил в firewalld порт, смог попасть. Перезагрузился, порт опять был закрыт. Я же его без permanent ключа разрешал. Оно работает.

denko
() автор топика
Ответ на: комментарий от anc

Попробуйте запустить tcpdump на хосте и удаленно telnet || nc на 53-й порт подключиться. Долетают хоть пакеты до вас?

Запустил tcpdump на сервере 

sudo tcpdump -vv -i eth0 port 53

На локальной машине telnet (адрес) 53

Telnet куда-то подключается, но пакетов на сервере я не вижу.

denko
() автор топика
Ответ на: комментарий от infomeh

блокировки чего-либо вообще не заметил

А она как раз есть. :)
A INPUT -j REJECT --reject-with icmp-host-prohibited

anc ★★★★★
()
Ответ на: комментарий от denko

ЧТД, происки провов. Скорее всего локального. Попробуйте с другого места nmap запустить.

anc ★★★★★
()
Ответ на: комментарий от denko

Вам все верно разъяснили firewalld это не более чем надстройка над netfilter.

firewall-cmd --add-port=19999/tcp

Вы могли написать
iptables -I INPUT -p tcp --dport 19999 -j ACCEPT
и оно тоже сработало бы.

anc ★★★★★
()
Ответ на: комментарий от anc

Вам все верно разъяснили firewalld это не более чем надстройка над netfilter.

Да я в курсе. Но все равно спасибо. Просто с серверами я работаю год только, времена без фаерволов не застал и даже не знаю стоит ли изучать iptables сейчас, когда все очень просто рулится через firewalld если на centos и прочих redhat. Я пока везде ставил CentOS, а там он из коробки уже стоит.

denko
() автор топика
Ответ на: комментарий от denko

На сервере запустите: 

sudo tcpdump -n -ieth0 udp and port 53
На внешнем (через инет) хосте запустите: 
sudo nmap -v -sU -Pn -p 53 <внешний IP адрес сервера>
Что покажет tcpdump?

funky ★
()
Ответ на: комментарий от denko

даже не знаю стоит ли изучать iptables сейчас

Скорее нет. iptables legacy несмотря на то что повсеместно используется, ваш пример тому подтверждение. Ему на смену nftables запилили. Если бы я сейчас начинал изучение fw то начал бы с nftables. Но сам пока не притрагивался, у меня много заточено под iptables+ipset и переписывать все это как минимум лень. И если трансляция правил iptables в nftables запилена, то с ipset проблемы, нет и вроде не планируют. Так что пока не припрет не буду переходить. Когда-то давно так же долго не переходил с ipchains на iptables.

когда все очень просто рулится через firewalld

Дистрспецифична, у убунту например ufw.

anc ★★★★★
()
Ответ на: комментарий от denko

Это Ваш «адрес» ломится на proxad.net. То бишь это Ваши запросы. А вот то, что к Вам не проходят пакеты на UDP 53 - это косяк хостера/провайдера. Ну или фича, в смысле защиты от DDOS или еще чего.

funky ★
()
Ответ на: комментарий от funky

Чаще всего это называется не «косяк», а запрет обхода блокировок. Этакая доморощенная разновидность в виде перенаправления dns запросов на свой сервер. Появилась на заре ввода блокировок.

Ну или фича, в смысле защиты от DDOS

Каким образом это защитит? Я понимаю если дропает пров на своем уровне, но дропает а не открытый порт.

anc ★★★★★
()
Ответ на: комментарий от denko

ЗЫ
Задумался по вашему вопросу

стоит ли изучать iptables сейчас

вы написали

просто рулится через firewalld

Не поверите, все тоже самое (я про ваши правила) «просто рулится iptables». firewalld ведь тоже надо уметь готовить.

Думаю для общего образования прочитать iptables tutorial вообще стоит. Он очень хорошо написан. Времени не так уж что бы и много займет, а понимания что именно мы делаем будет больше.

anc ★★★★★
()
Ответ на: комментарий от anc

Чаще всего это называется не «косяк», а запрет обхода блокировок. Этакая доморощенная разновидность в виде перенаправления dns запросов на свой сервер. Появилась на заре ввода блокировок.

Да, скорее всего, провайдер. Проверил nmap'ом с сервера в Европе нет этого открытого порта.

Значит, провайдер на стороне локальной машины, с которой проверял ловит трафик на этот порт.

denko
() автор топика
Ответ на: комментарий от anc

В целом согласен. Это я вспомнил, что встречал хостеров, у которых была защита с предварительным установлением tcp/ip соединения, после которого соединение пропускалось до VDS. Но случай ТС явно не тот. У него еще похоже на принудительное прозрачное заворачивание udp/53 запросов на свой собственный кеширующий dnsmasq на роутере.

funky ★
()
Ответ на: комментарий от denko

Проверил nmap'ом с сервера в Европе нет этого открытого порта.

«Ну и зашибись». Вопрос локализован. Отмечайте как решенную. :)

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Проблемы с именем хоста JITSI-MEET
Admin
KDE5/AlienBob/Slackware-14.2_x64 on VirtualBox →