LINUX.ORG.RU

Что-то странное с сервисами и портами на свежем дебиане 8

 ,


0

5

Просканировал nmap -sT -p 1-65535 внешний IP своего локалхоста и заметил, что несколько портов в адресах 30000 и более открыты. rpc.statd - это от NFS сервис вроде может их открывать.

service --status-all показывает, что да, запущен nfs-common. Поскольку мне NFS сейчас не нужен остановил сервис и даже удалил пакет nfs-common.

Тем не менее, сейчас вот обнаружил, что хотя nfs-common в списке установленных пакетов отсутствует, в списке сервисов он благополучно присутствует и активен! Это что такое? ps -A|grep nfs-common ничего не показывает. service nfs-common stop его останавливает. Кажется до следующей перезагрузки :)

Далее, кто-то всё-равно иногда открывает неизвестные порты. nmap показывает, что они бывают иногда открыты, но на короткое время. Последующие запуски nmap могут показать, что ничего не открыто (всякие cups я закрыл iptables от внешнего мира), а иногда что что-то открыто.

К сожалению, никак не могу узнать какая задача/сервис их открывает. netstat -ctvaep не успевает зафиксировать. Как бы это сделать?

Что-то раньше такого странного поведения у системы не было, это особенности нового Debian или таки похакали, хотя непонятно кто и когда и как, потому что только установил его и ничего особенного не делал.

Вообще достаточно сразу сделать

systemctl stop nfs-common
systemctl disable nfs-common
Но есть небольшой интерес в том, что ты написал. Копаем дальше. Исхожу из ситуации в debian 8 по дефолту.
service --status-all | grep nfs
 [ - ]  mountkernfs.sh
 [ - ]  mountnfs-bootclean.sh
 [ - ]  mountnfs.sh
 [ + ]  nfs-common
 [ ? ]  qemu-system-x86
 [ - ]  umountnfs.sh
найдем пакет по имени файла
dpkg -S nfs-common
nfs-common: /usr/share/bug/nfs-common/script
nfs-common: /etc/init.d/nfs-common
nfs-common: /usr/share/doc/nfs-common/copyright
nfs-common: /usr/share/lintian/overrides/nfs-common
nfs-common: /usr/share/doc/nfs-common
nfs-common: /usr/share/nfs-common/conffiles/nfs-common.default
nfs-common: /usr/share/doc/nfs-common/README.Debian.nfsv4
nfs-common: /usr/share/nfs-common/conffiles
nfs-common: /usr/share/nfs-common/conffiles/idmapd.conf
nfs-common: /usr/share/bug/nfs-common
nfs-common: /usr/share/doc/nfs-common/changelog.Debian.gz
nfs-common: /usr/share/nfs-common
nfs-common: /etc/default/nfs-common
nfs-common: /usr/share/bug/nfs-common/control
удалим
apt-get remove nfs-common
Проверим
#  service --status-all | grep nfs
 [ - ]  mountkernfs.sh
 [ - ]  mountnfs-bootclean.sh
 [ - ]  mountnfs.sh
 [ - ]  nfs-common
 [ ? ]  qemu-system-x86
 [ - ]  umountnfs.sh
Дальше и вправду прикол. Может сделаны костыли для совместимости sysvinit
# systemctl disable nfs-common
Synchronizing state for nfs-common.service with sysvinit using update-rc.d...
Executing /usr/sbin/update-rc.d nfs-common defaults
Executing /usr/sbin/update-rc.d nfs-common disable
insserv: warning: current start runlevel(s) (empty) of script `nfs-common' overrides LSB defaults (S).
insserv: warning: current stop runlevel(s) (0 1 6 S) of script `nfs-common' overrides LSB defaults (0 1 6).
# dpkg -S nfs-common
nfs-common: /etc/init.d/nfs-common
nfs-common: /etc/default/nfs-common
# systemctl status nfs-common
● nfs-common.service - LSB: NFS support files common to client and server
   Loaded: loaded (/etc/init.d/nfs-common)
   Active: inactive (dead)

окт 23 18:45:46 andrew667-laptop rpc.statd[561]: Version 1.2.8 starting
окт 23 18:45:46 andrew667-laptop sm-notify[562]: Version 1.2.8 starting
окт 23 18:45:47 andrew667-laptop nfs-common[556]: Starting NFS common util...
окт 23 23:14:08 andrew667-laptop nfs-common[7528]: Stopping NFS common uti...
Hint: Some lines were ellipsized, use -l to show in full.

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

Интересно. Значит вряд ли нас одинаково поломали. Однако, что-то грязно работать стали в Debian, таких шуток вроде раньше не было.

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

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

Сделай дамп трафика. Может это прояснит ситуацию.

Значит вряд ли нас одинаково поломали.

Я не считаю систему поломаной. У меня jessie без всякой дополнительной дряни и бэкпортов. В RHEL, например, во freeradius даже если закомментировать неиспользуемый sqlite, то freeradius не работает, пока не установить модуль для sqlite. Тут может быть нечто похожее. То есть остались файлы /etc/init.d/nfs-common и /etc/default/nfs-common, относящиеся к другому пакету, хотя поиск говорит только о пакете nfs-common. Или сделан грязный хак для совместимости.

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

Сделай дамп трафика. Может это прояснит ситуацию.

Сделал при закрытом браузере и т.п. Что-то у меня такое ощущение, что я неточно понимаю как работает TCP/IP и ядро в ответ на входящие соединения, я что-то запутался уже, порты должны быть закрыты, даже если отлуп на входящее соединение посылается или нет? Или если не фильтрованы в iptables на короткое время nmap их может найти открытыми? Если так, то ничего особенного.

Есть пара непонятных вещей:

1) Одиночный запрос к моему компу и обратно с адресом по которому whois выдаёт это:

inetnum:        123.151.148.0 - 123.151.151.255
netname:        TIANJIN-HAOWEIGAOKE-LTD
descr:          HAOWEIGAOKE-LTD
descr:          TIANJIN CITY
country:        CN
admin-c:        AT370-AP
tech-c:         AT370-AP
mnt-by:         MAINT-CHINANET-TJ
status:         ASSIGNED NON-PORTABLE
changed:        guanglan0322@163.com 20081022
source:         APNIC

person:         admin tjtele
nic-hdl:        AT370-AP
e-mail:         tjipback@yahoo.com
address:        No.11 LIUJING ROAD ,HEDONG ,TIANJIN,CHINA
phone:          +86-22-85580499
fax-no:         +86-22-85580970
country:        CN
changed:        ipadmin@north.cn.net 20060508
changed:        zhengzm@gsta.com 20140401
mnt-by:         MAINT-CHINANET-TJ
source:         APNIC

обозначенный в wireshark как ms-wbt-server, запрос и ответ от меня:

Transmission Control Protocol, Src Port: 22204 (22204), Dst Port: ms-wbt-server (3389), Seq: 0, Len: 0

Transmission Control Protocol, Src Port: ms-wbt-server (3389), Dst Port: 22204 (22204), Seq: 1, Ack: 1, Len: 0

и примерно такое, смотри скриншот. Мой комп - 77.24x.xxx.xxx http://s017.radikal.ru/i443/1510/9a/64085930abcb.png

anonymous_incognito ★★★★★
() автор топика

ps -A|grep nfs-common ничего не показывает

facepalm, nfs-common запускает rpc.statd

most-fucktum
()

Просканировал nmap -sT -p 1-65535 внешний IP своего локалхоста

открой для себя

netstat -tunelp

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

Он всё-равно не показывает те случайно открываемые порты. У меня такое ощущение, что это просто какая-то особенность работы ядра Linux в ответ на некоторые входящие сообщения.

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

Ещё раз объясняю.

Запускаю nmap -sT -p 1-65535 и где-то из трёх-четырёх запусков один-два случайных порта будут открыты. Каждый раз в этой серии запусков разные.

Например,

PORT      STATE SERVICE
50790/tcp open  unknown

Но к моменту, когда я это увидел уже всё закрыто. И два-три раза подряд запусков nmap будет будет закрыто, а потом допустим какой-нибудь 39908-й порт открыт.

netstat даже с опцией -c (раз в секунду обновлять данные) не поймал это открытие порта.

Вот сейчас повторил эксперимент c тем, что ты предложил. В одном окне:

#netstat -ctunelp >netstat_20151024a

В другом окне через несколько секунд запускал nmap, который два запуска подряд выдал, что все порты закрыты, но третий раз

PORT      STATE SERVICE
50383/tcp open  unknown
51616/tcp open  unknown

На четвёртый - снова все порты закрыты, а на пятый открыт один 45009

# cat netstat_20151024a |grep 50383
# cat netstat_20151024a |grep 51616
# cat netstat_20151024a |grep 45009

ничего не находят (ну и просто поиском в gedit, на всякий случай)

В тоже время это здорово похоже на то, что замечено было в tcpdump несколько постов выше: Что-то странное с сервисами и портами на свежем дебиане 8 (комментарий)

http://s017.radikal.ru/i443/1510/9a/64085930abcb.png

На скриншоте видно, что порт 51413 на короткое время открывался, хотя с него фактически ничего не улетало, кроме RST/ACK и я даже предполагаю, что так и должно было быть и я напрасно беспокоюсь, но тем не менее.

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

Не знаю, может и связано, но вроде и другие порты были. Transmission я же уже несколько суток не запускал.

anonymous_incognito ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.