NodeJS - ошибка npm undefined symbol uv_fs_realpath

В большинстве сред вы ожидаете найти только сокеты tcp, udp, raw и packet. К счастью, ss знает обо всех них.

Предполагая, что ss знает все необходимые вам протоколы, я могу использовать следующую команду. Это исключит сокеты "unix". Она также исключит сокеты "netlink", которые используются только для связи с локальным ядром.

sudo ss -l -p | grep -vE '^(u_|nl )'

Часто у вас не так много прослушивающих сокетов. Поэтому вы можете просмотреть их все и вручную проигнорировать те, которые прослушивают loopback IP-адреса. В качестве альтернативы, вы можете попросить ss сделать всю фильтрацию:

sudo ss -l -p -A 'all,!unix,!netlink' 'not src 127.0.0.1 not src [::1]'

В обоих случаях вывод может также включать "клиентские" udp-сокеты. Таким образом, он может также показать DNS-клиенты, HTTP/3-клиенты, ...

Если вам не нужно видеть информацию о программе, которая открыла каждый сокет, то вы можете убрать опцию -p, и вам не нужно запускать ss (или netstat) с привилегиями root (sudo).

Насколько всеобъемлющей является приведенная выше команда?

Несмотря на то, что она рекламируется как замена netstat, ss не поддерживает показ "udplite" сокетов.

Кроме того, ответ зависит от вашей версии ss (и, полагаю, ядра тоже). Когда этот ответ был первоначально написан, до 2017, ss не поддерживал "sctp". netstat поддерживал его с февраля 2014 года). sctp ожидается именно внутри телефонных компаний. За пределами телефонных компаний VOIP обычно использует udp.

К сожалению, если вы ищете полный список в man netstat, он становится довольно запутанным. Опции для sctp и udplite показаны в первой строке, наряду с tcp, udp и raw. Далее внизу есть то, что выглядит как полный список семейств протоколов семейств: [-4|--inet] [-6|--inet6] [--unix|-x] [--inet|--ip|--tcpip] [--ax25] [--x25] [--rose] [--ash] [--bluetooth] [--ipx] [--netrom] [--ddp|--appletalk] [--econet|--ec].

Хотя netstat поддерживает udplite и sctp, он не поддерживает "dccp". Также netstat не поддерживает пакетные сокеты (как сырые сокеты, но включающие заголовки уровня соединения), как выбрано ss -l -0. В заключение, я ненавижу все, и я, вероятно, мог бы быть менее педантичным.

Также ss не поддерживает bluetooth-сокеты. Bluetooth-розетки не являются традиционной проблемой. Это может быть актуально, если вы проводите полный аудит. Однако безопасность Bluetooth - довольно специфический вопрос; я не буду отвечать на него здесь.

Опускать localhost в netstat?

netstat не имеет специального способа опустить сокеты, привязанные к localhost. Вы можете использовать | grep -...v в конце. Будьте осторожны, если вы используете опцию -p в netstat / ss. Вы можете случайно исключить некоторые процессы, если в имени процесса есть совпадение. Я бы включил двоеточие в шаблон, например grep -v localhost:. За исключением того, что по умолчанию в ss отображаются числовые адреса, так что в этом случае вы бы использовали | grep -vE (127.0.0.1|\[::1\]):. Я полагаю, вы можете попытаться проверить процессы, которые будут случайно исключены, например, ps ax | grep -E (127.0.0.1|\[::1\]):.

Есть ли более простая команда?

Жаль, что дело касается пакетных сокетов. В противном случае, я бы предложил простую команду netstat -l. netstat, предвосхищая ваш запрос, разделяет вывод на "Интернет-соединения", "сокеты домена UNIX" и "Bluetooth-соединения". Вам достаточно посмотреть на первый раздел. Для сокетов netlink раздела нет.

Предположим, что вас интересуют только сокеты tcp, udp, raw и packet. Для первых трех типов сокетов вы можете использовать netstat -l -46.

Пакетные сокеты широко используются. Поэтому вам также придется приучить себя запускать ss -l -0 (или ss -l --packet).

К сожалению, это оставляет вас с большим подводным камнем. Проблема в том, что теперь возникает соблазн попробовать объединить эти две команды...

Ловушки, которых следует избегать при использовании ss

ss -l -046 выглядит привлекательно в качестве ответа одной командой. Однако это не так. ss -46 показывает только сокеты IPv6. ss -64 показывает только IPv4 сокеты.

Я рекомендую всегда проверять свои результаты на вменяемость. Узнайте, чего ожидать; пройдитесь по каждому протоколу и посмотрите, нет ли там чего-то, что должно там быть. Если у вас нет адресов IPv4 или нет адресов IPv6, это очень подозрительно. Можно ожидать, что на большинстве серверов есть служба SSH, прослушивающая оба протокола. Большинство несерверов также должны показывать пакетные или необработанные сокеты из-за использования DHCP.

Если вы не хотите интерпретировать вывод двух разных команд, альтернативой может быть замена команды netstat на ss -l -A inet. Это немного неудачно, потому что при запуске netstat точно такие же параметры исключают сокеты ipv6.

Поэтому для одной команды можно использовать ss -l -A inet,packet ... .

IMO вы могли бы также использовать ss -l | grep ... , как я предлагал в первом разделе. Эту команду легко запомнить, и она позволяет избежать любой путаницы в опциях выбора ss.

Хотя если вы пишете сценарии, которые используют этот вывод для автоматизации, то, вероятно, лучше предпочесть вместо этого фильтрацию по положительному списку типов сокетов. Иначе сценарий может сломаться, когда ss начнет поддерживать новый тип локального сокета.

Я упоминал, что ss -a -A raw -f link показывает комбинацию сокетов из ss -a -A raw и ss -a -f link? Тогда как ss -a -A inet -f inet6 показывает меньше сокетов, чем ss -a -A inet? Я думаю, что -f inet6 и -f inet - это особые случаи, которые не документированы должным образом.

(-0, -4 и -6 являются псевдонимами для -f link, -f inet и -f inet6).

Я уже упоминал, что ss -A packet покажет заголовки, но никогда не покажет ни одного сокета? strace показывает, что он буквально ничего не читает. Похоже, это происходит потому, что он рассматривает пакетные сокеты как всегда "слушающие". ss не удосужился выдать предупреждение об этом. И это отличается от сырых сокетов, которые ss рассматривает как одновременно "слушающие" и "не слушающие".

(man 7 raw говорит, что если raw сокет не привязан к определенному протоколу, который не привязан к определенному IP протоколу, то он является transmit-only. Я не проверял, рассматриваются ли они только как слушающие сокеты)