Linux lsof tcp port

Как проверить открытые порты в Linux (используемые порты)

How to Check for Listening Ports in Linux (Ports in use)

В этой статье объясняется , как узнать, какие услуги прослушивает порты с помощью netstat, ss и lsof команд. Инструкции применимы для всех операционных систем на базе Linux и Unix, таких как macOS.

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

Что такое открытый порт (порт прослушивания)

Сетевой порт идентифицируется его номером, соответствующим IP-адресом и типом протокола связи, таким как TCP или UDP.

Порт прослушивания — это сетевой порт, который прослушивает приложение или процесс, выступая в качестве конечной точки связи.

Каждый порт прослушивания может быть открыт или закрыт (отфильтрован) с помощью брандмауэра. В общих чертах, открытый порт — это сетевой порт, который принимает входящие пакеты из удаленных мест.

Вы не можете иметь две службы, прослушивающие один и тот же порт на одном и том же IP-адресе.

Например, если вы используете веб-сервер Apache, который прослушивает порты, 80 и 443 вы пытаетесь установить Nginx, позднее не удастся запустить, потому что порты HTTP и HTTPS уже используются.

Проверьте порты прослушивания с netstat

netstat это инструмент командной строки, который может предоставить информацию о сетевых подключениях

Чтобы получить список всех прослушиваемых портов TCP или UDP, включая службы, использующие порты и состояние сокета, используйте следующую команду:

Параметры, используемые в этой команде, имеют следующее значение:

• -t — Показать порты TCP.
• -u — Показать порты UDP.
• -n — Показать числовые адреса вместо разрешения хостов.
• -l — Показывать только порты прослушивания.
• -p — Показать PID и имя процесса слушателя. Эта информация отображается, только если вы запускаете команду от имени пользователя root или sudo .

Вывод будет выглядеть примерно так:

Важными столбцами в нашем случае являются:

• Proto — Протокол, используемый сокетом.
• Local Address — IP-адрес и номер порта, на котором слушает процесс.
• PID/Program name — PID и название процесса.

Если вы хотите отфильтровать результаты, используйте команду grep . Например, чтобы узнать, какой процесс прослушивает TCP-порт 22, вы должны набрать:

Выходные данные показывают, что на этой машине порт 22 используется сервером SSH:

Если вывод пуст, это означает, что ничего не прослушивает порт.

Вы также можете отфильтровать список на основе критериев, например, PID, протокола, состояния и т. Д.

netstat устарел и заменен на ss и ip , но все же это одна из наиболее часто используемых команд для проверки сетевых подключений.

Проверьте порты прослушивания с ss

ss новый netstat . В нем отсутствуют некоторые netstat функции, но он предоставляет больше состояний TCP и работает немного быстрее. Параметры команды в основном одинаковы, поэтому переход с netstat на ss не сложен.

Чтобы получить список всех прослушивающих портов ss , наберите:

Вывод почти такой же, как тот, о котором сообщили netstat :

Проверьте порты прослушивания с lsof

lsof это мощная утилита командной строки, которая предоставляет информацию о файлах, открытых процессами.

В Linux все это файл. Вы можете думать о сокете как о файле, который пишет в сеть.

Чтобы получить список всех прослушивающих TCP-портов, lsof введите:

Используются следующие параметры:

• -n — Не конвертируйте номера портов в имена портов.
• -p — Не разрешайте имена хостов, показывайте числовые адреса.
• -iTCP -sTCP:LISTEN — Показывать только сетевые файлы с состоянием TCP LISTEN.

Большинство имен выходных столбцов говорят сами за себя:

• COMMAND , PID , USER — имя, ИДП и пользователь , запустив программу , связанную с портом.
• NAME — номер порта.

Чтобы узнать, какой процесс прослушивает определенный порт, например, порт, который 3306 вы используете:

Выходные данные показывают, что порт 3306 используется сервером MySQL:

Для получения дополнительной информации посетите страницу руководства lsof и прочитайте обо всех других мощных опциях этого инструмента.

Вывод

Мы показали вам несколько команд, которые вы можете использовать для проверки того, какие порты используются в вашей системе, и как найти процесс, который прослушивает определенный порт.

Источник

Linux Find Out Which Process Is Listening Upon a Port

Linux Find Out Which Process Is Listening Upon a Port

You can the following programs to find out about port numbers and its associated process:

1. netstat command or ss command – a command-line tool that displays network connections, routing tables, and a number of network interface statistics.
2. fuser command – a command line tool to identify processes using files or sockets.
3. lsof command – a command line tool to list open files under Linux / UNIX to report a list of all open files and the processes that opened them.
4. /proc/$pid/ file system – Under Linux /proc includes a directory for each running process (including kernel processes) at /proc/PID, containing information about that process, notably including the processes name that opened port.

You must run above command(s) as the root user.

Linux netstat command find out which process is listing upon a port

Type the following command:
# netstat -tulpn
Sample outputs:

TCP port 3306 was opened by mysqld process having PID # 1138. You can verify this using /proc, enter:
# ls -l /proc/1138/exe
Sample outputs:

You can use grep command or egrep command to filter out information:
# netstat -tulpn | grep :80
Sample outputs:

A note about ss command

Some Linux distro considered the nestat command as deprecated and therefore should be phased out in favor of more modern replacements such as ss command. The syntax is:
$ sudo ss -tulpn
$ sudo ss -tulpn | grep :3306

Click to enlarge image

Video demo

fuser command

Find out the processes PID that opened tcp port 7000, enter:
# fuser 7000/tcp
Sample outputs:

Finally, find out process name associated with PID # 3813, enter:
# ls -l /proc/3813/exe
Sample outputs:

/usr/bin/transmission is a bittorrent client, enter:
# man transmission
OR
# whatis transmission
Sample outputs:

Find Out Current Working Directory Of a Process

To find out current working directory of a process called bittorrent or pid 3813, enter:
# ls -l /proc/3813/cwd
Sample outputs:

OR use pwdx command, enter:
# pwdx 3813
Sample outputs:

• No ads and tracking
• In-depth guides for developers and sysadmins at Opensourceflare✨
• Join my Patreon to support independent content creators and start reading latest guides:
  • How to set up Redis sentinel cluster on Ubuntu or Debian Linux
  • How To Set Up SSH Keys With YubiKey as two-factor authentication (U2F/FIDO2)
  • How to set up Mariadb Galera cluster on Ubuntu or Debian Linux
  • A podman tutorial for beginners – part I (run Linux containers without Docker and in daemonless mode)
  • How to protect Linux against rogue USB devices using USBGuard

Join Patreon ➔

Find Out Owner Of a Process on Linux

Use the following command to find out the owner of a process PID called 3813:
# ps aux | grep 3813
OR
# ps aux | grep ‘[3]813’
Sample outputs:

OR try the following ps command:
# ps -eo pid,user,group,args,etime,lstart | grep ‘[3]813’
Sample outputs:

Another option is /proc/$PID/environ, enter:
# cat /proc/3813/environ
OR
# grep —color -w -a USER /proc/3813/environ
Sample outputs (note –colour option):

Fig.01: grep output

lsof Command Example

Type the command as follows:

Now, you get more information about pid # 1607 or 1616 and so on:
# ps aux | grep ‘[1]616’
Sample outputs:
www-data 1616 0.0 0.0 35816 3880 ? S 10:20 0:00 /usr/sbin/apache2 -k start
I recommend the following command to grab info about pid # 1616:
# ps -eo pid,user,group,args,etime,lstart | grep ‘[1]616’
Sample outputs:

• 1616 : PID
• www-date : User name (owner – EUID)
• www-date : Group name (group – EGID)
• /usr/sbin/apache2 -k start : The command name and its args
• 03:16:22 : Elapsed time since the process was started, in the form [[dd-]hh:]mm:ss.
• Fri Oct 29 10:20:17 2010 : Time the command started.

Help: I Discover an Open Port Which I Don’t Recognize At All

The file /etc/services is used to map port numbers and protocols to service names. Try matching port numbers:
$ grep port /etc/services
$ grep 443 /etc/services
Sample outputs:

Check For rootkit

I strongly recommend that you find out which processes are really running, especially servers connected to the high speed Internet access. You can look for rootkit which is a program designed to take fundamental control (in Linux / UNIX terms “root” access, in Windows terms “Administrator” access) of a computer system, without authorization by the system’s owners and legitimate managers. See how to detecting / checking rootkits under Linux.

Keep an Eye On Your Bandwidth Graphs

Usually, rooted servers are used to send a large number of spam or malware or DoS style attacks on other computers.

Conlcusion

You learned various Linux commands to find information about running process and their ports. See the following man pages for more information:
$ man ps
$ man grep
$ man lsof
$ man netstat
$ man fuser

🐧 Get the latest tutorials on Linux, Open Source & DevOps via

Источник

Удивительно полезный инструмент: lsof

Я привык искать проблемы в коде или в системе, пользуясь логами или показателями мониторинга, которые выводятся на симпатичных панелях управления с простым и понятным интерфейсом. Однако, если по какой-то причине данные на панель управления не поступают, или логи какой-нибудь службы недоступны, отладка усложняется. Теперь подобных проблем немного, встречаются они редко, но они, всё же, случаются. Поэтому и в наше время весьма ценно знание инструментов, которые помогают понять, что не так с неким процессом на каком-нибудь компьютере.

Когда я отлаживаю нечто, для чего нет логов или показателей мониторинга, я подключаюсь к удалённому компьютеру по ssh. Конечно, это подход ограниченный, он не так уж и прост, не соответствует модным веяниям DevOps, или всем тем современным штучкам, которых можно начитаться в интернете, но он на удивление хорошо подходит мне для того, чтобы быстро проанализировать ситуацию.

Это, на самом деле, похоже на использование команды print при отладке программ. Тут мне сразу хотелось бы уточнить, что я не SRE и не инженер по эксплуатации в сфере IT. Основная сфера моей деятельности — разработка.

Иногда мне приходится разворачивать код, который я написал, и отлаживать его, когда что-то идёт не так. Почти всегда, когда я оказываюсь в новой для себя системе, самым сложным для меня оказывается поиск чего-либо . Например — выяснить, какой порт прослушивает процесс. Или, что требуется чаще, узнать, в какой файл пишет логи некий демон. И если даже мне удаётся найти ответы на эти вопросы, воспользовавшись кучей вызовов команд ps , pstree и ls , и великим множеством обращений к команде grep , часто «ответы», которые я нахожу, либо не содержат ничего полезного, либо оказываются неверными.

Если бы то, что вы сейчас читаете, было бы выступлением Раймонда Геттингера, ведущего разработчика CPython, тут настал бы момент, когда аудитория ждёт фразы: «должен быть лучший способ».

И, на самом деле, такой способ есть. Средством, которым я постоянно пользуюсь для поиска в системе того, что мне нужно, стал отличный инструмент, который называется lsof .

Утилита lsof (её название звучит как el-soff, хотя некоторым больше нравится нечто вроде liss-off или даже el-es-o-eff) — это невероятно полезная команда, которая выводит список всех открытых файлов (LiSts all Open Files).

Команд lsof особенно хороша для поиска чего-либо, так как в Unix-подобных системах всё является файлом. Это — на удивление универсальный отладочный инструмент, который довольно легко способен заменить утилиты ps , netstat , да и некоторые другие тоже.

Опции lsof

Ветеран SRE, который занимался этим делом за десятилетия до того, как появился термин «SRE», однажды сказал мне: «Я перестал изучать опции lsof как только узнал все те, которые мне нужны. Изучи самое важное, и это будет всем, что тебе когда-либо понадобится».

Утилита lsof имеет обширный набор опций.

Если вы хотите изучит их все — man вам в помощь. Здесь же мне хотелось бы рассказать о тех, которыми обычно пользуюсь я.

▍Опция -u

Опция -u выводит список файлов, открытых конкретным пользователем. Следующий пример показывает, как можно узнать, сколько файлов держит открытыми пользователь cindy .

Обычно, если перед параметром некоей опции ставят знак «^» (крышка), который означает отрицание, это приводит к исключению файлов, соответствующих данному параметру, из вывода программы. Вот, например, как можно узнать количество файлов на компьютере, которые открыты всеми пользователями за исключением cindy .

▍Опция -U

Опция -U позволяет вывести все файлы сокетов домена Unix.

▍Опция -c

Опция -c позволяет вывести сведения о файлах, которые держат открытыми процессы, выполняющие команды, имена которых начинаются с заданных символов. Например, вот какая команда позволит увидеть первые 15 файлов, открытых всеми процессами Python, выполняющимися на компьютере.

Вот ещё интересный пример. Например, имеется некоторое количество процессов Python 2.7 и Python 3.6, при этом надо выяснить, какие файлы открыты процессами, которые не являются процессами Python 2.7. Сделать это можно так:

▍Опция +d

Опция +d позволяет выяснить, какие папки и файлы открыты в некоей директории (но не в её поддиректориях).

▍Опция -d

Пожалуй, опция -d — это одна из тех, которыми я пользуюсь чаще всего. Уступает она только опции -p . Эта опция позволяет задать список дескрипторов файлов, разделённых запятой, которые надо включить в вывод или исключить из него. Вот что говорит об этом документация:

Список исключается из вывода, если все записи в наборе начинаются со знака «^». Список будет включён в вывод, если ни одна запись не начинается с «^». Смешивание записей разных видов не разрешается.

В списке может присутствовать диапазон номеров дескрипторов файлов при условии, что ни один из его членов не пуст, оба члена являются числами, и завершающий член больше начального — то есть: «0-7» или «3-10».

Диапазоны могут быть использованы для исключения записей из вывода, если перед ними стоит префикс «^», то есть — «^0-7» исключает все дескрипторы с 0 по 7.

Вывод по нескольким номерам дескрипторов файлов объединяется в соответствии с правилами логического ИЛИ, в один набор, прежде чем к ним будет применена операция логического И.

Когда в наборе встречаются и включаемые и исключаемые члены, lsof сообщает об ошибке и завершает работу с ненулевым кодом возврата.

▍Опция -p

Не могу вспомнить, когда я не пользовался бы опцией -p , работая с lsof . Она позволяет вывести все файлы, открытые процессом с указанным при вызове команды PID.

Например, вот как в Ubuntu выглядит вывод информации обо всех файлах, открытых процессом, скажем, с PID 1.

Вывод команды lsof, вызванной с опцией -p в Ubuntu

Вот что выводится на моём MacBook Air.

Вывод команды lsof, вызванной с опцией -p на MacBook Air

▍Опция -P

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

Эту опцию можно использовать с другой опцией — -n , которая подавляет преобразование сетевых номеров в имена хостов для сетевых файлов. Она, кроме того, полезна при неправильно работающем разрешении имён хостов.

Подавление обоих вышеупомянутых преобразований иногда может ускорить работу lsof .

▍Опция -i

Опция -i позволяет вывести сведения о файлах, интернет-адреса которых соответствуют заданному адресу. Если при вызове команды не задавать адреса, эта опция позволяет вывести сведения обо всех интернет-сокетах и сетевых файлах.

С помощью lsof можно, например, посмотреть на TCP-соединения, открытые клиентом Slack или Dropbox. Ради интереса попробуйте посмотреть, сколько соединений открывают вкладки Chrome, каждая из которых является отдельным процессом. Посмотрим на соединения, открытые Slack:

Вывод сведений о соединениях, которые открыл Slack

А вот что с помощью lsof можно узнать о TCP-сокетах, открытых клиентом Dropbox:

Вывод сведений о соединениях, которые открыл Dropbox

Lsof позволяет просматривать и сведения об UDP-соединениях с помощью команды lsof -iUDP .

Вывод сведений об UDP-соединениях

С помощью команды lsof -i 6 можно вывести список открытых соединений IPv6.

Вывод сведений об IPv6-соединениях

▍Опция -t

Опция -t подавляет вывод всей информации за исключением ID процессов. Я часто использую её, если хочу перенаправить список PID какой-нибудь другой команде, в основном — kill-9 .

Комбинирование опций

Обычно lsof объединяет результаты использования нескольких опций, следуя принципу логического ИЛИ. Если задать опцию -a , результаты будут объединены по правилам логического И.

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

Обычно заданные опции списка объединяются по принципу логического ИЛИ, то есть, если указать опцию -i без указания адреса, и опцию -u foo, будет выведен список всех сетевых файлов или файлов, принадлежащих процессам, владельцем которых является пользователь «foo». Из этого правила есть несколько исключений:

1. Имя пользователя или ID пользователя (UID) со знаком «^» (отрицание), заданное с опцией -u;
2. Идентификатор процесса (PID) со знаком «^» (отрицание), заданный с опцией -p;
3. Группа процессов (PGID) со знаком «^» (отрицание), заданная с опцией -g;
4. Имя команды со знаком «^» (отрицание), заданное с опцией -c;
5. Имена состояний протоколов TCP или UDP, заданные с опцией -s [p:s].

Так как всё это — команды для исключения результатов из вывода, они применяются без использования принципов логического ИЛИ или И, они воздействуют на вывод команды до применения любых других критериев отбора.

Опцию -a можно использовать для обработки вывода по принципу логического И. Например, если использовать опции -a, -U и -u foo, будет выведен список только файлов сокетов UNIX, которые принадлежат процессам, владельцем которых является пользователь «foo».

История большой победы

Пожалуй, я тут немного преувеличиваю, «победа» была не такой уж и большой, но когда случилось то, о чём пойдёт речь, lsof оказался очень кстати.

Пару недель назад мне нужно было поднять один экземпляр нового сервиса в тестовом окружении. Тестовый сервис, о котором идёт речь, не был подключён к рабочей инфраструктуре мониторинга. Я попытался выяснить, почему процесс, который был только что запущен, не зарегистрировал себя в Consul, как результат, его не могли обнаружить другие сервисы. «Так, не знаю, в чём дело, но взгляну-ка я на логи», — подумал я. Если что-то работает не так, как ожидается, я смотрю логи сервиса, работу которого пытаюсь наладить, и в большинстве случаев логи сразу указывают на корень проблемы.

Сервис, о котором идёт речь, запускался с использованием менеджера процессов и сокетов circus. Логи для процессов, работающих под circus , хранятся в специальном месте на хосте — назовём его /var/log/circusd . Более новые сервисы на хосте запускались другим менеджером, s6, который пишет логи в другое место. Затем, есть ещё и логи, которые генерирует socklog/svlogd, которые, опять же, оказываются где-то ещё. Короче говоря, в логах недостатка не было, и главная проблема заключалась в том, чтобы обнаружить, в какой дескриптор файла пишет лог мой сбойный процесс.

Так как я знал, что процесс, с проблемами которого я пытался разобраться, работает под circus , подключение с помощью команды tail к /var/log/circusd/whatever_tab_completion_suggested позволило бы мне посмотреть на потоки stdout и stderr этого процесса. Правда, просмотр лога мне не дал абсолютно ничего. Быстро стало ясно, что я читал не тот лог-файл, и действительно, при ближайшем рассмотрении оказалось, что в /var/log/circusd было два файла: stage-svcname-stderr.log и staging-svcname.stderr.log . Я тогда воспользовался для автозавершения команды клавишей Tab, и тот файл, который был выбран автоматически, оказался не тем, что был нужен мне.

Один из способов понять, какой файл был действительно использован интересующим меня процессом для логирования, заключался в использовании команды lsof -l filename , которая вывела бы сведения обо всех процессах, имеющих открытые дескрипторы файлов. Оказалось, что ни с одним из работающих процессов не было ассоциировано лог-файла, который я просматривал с помощью команды tail , что означало, что этот файл можно было безопасно удалить.

Просмотр другого файла тут же позволил выяснить, почему процесс давал сбой (при этом circus перезапускал его после сбоя, что приводило к бесконечному циклу сбоев-перезапусков).

Итоги

Чем чаще я использую команду lsof , тем больше других инструментов она заменяет и тем больше полезного позволяет мне узнать. Надеюсь, теперь у lsof есть шанс принести пользу и вам.

Уважаемые читатели! Какими средствами командной строки Linux, которые не особенно широко известны, вы пользуетесь чаще всего?

Источник