Есть ли на серверах Centos журнал, который регистрирует каждое входящее/исходящее соединение?
так что-то вроде централизованного журнала подключений
решение1
Единственный надежный способ получить единый централизованный журнал всех TCP-соединений — добавить LOGправила в конфигурацию вашего iptablesпрограммного брандмауэра, которые будут регистрировать любой пакет с установленными битами SYN и ACK, т. е. второй пакет любого TCP-соединения. По умолчанию они будут отображаться как сообщения журнала ядра /var/log/messages.
Пожалуйста, посмотриэтот вопрос на Server Fault.SE.
По сути, вам нужно будет добавить такие правила iptables:
iptables -A OUTPUT -p tcp --tcp-flags SYN,ACK SYN,ACK -j LOG --log-prefix "Inbound connection established: "
iptables -A INPUT -p tcp --tcp-flags SYN,ACK SYN,ACK -j LOG --log-prefix "Outbound connection established: "
(Возможно, вы захотите поместить эти правила в существующий набор правил, чтобы они не применялись к интерфейсу обратной связи, поскольку это может привести к созданию двух записей для каждого локального соединения между процессами приложений на хосте.)
И да, правило в цепочке OUTPUT записывает входящие соединения и наоборот, потому что это будет регистрировать только соединения, на которые фактически отвечают: запись только пакетов SYN также будет регистрировать попытки соединения, которые будут отклонены. Из-за сканирования портов, выполняемого вредоносными системами в Интернете, это часто давало бы вам много бесполезных записей в журнале: вам пришлось бы перепроверять с другими журналами, только чтобы узнать, что либо у вас вообще не запущена такая служба, либо что соединение было отклонено другим iptablesправилом или рассматриваемой службой.
Для протоколов UDP все сложнее, потому что UDP не имеет соединения и по сути является просто платформой, на которой может быть построен протокол, специфичный для приложения. Поэтому нет простого способа обнаружить "первый пакет соединения" или что-то в этом роде, потому что все это будет полностью специфично для приложения.
решение2
Я думаю, это должно подойти:
journalctl -fu sshd
или
journalctl -u sshd -n 100
То есть, если вы используете systemd, который, как я думаю, используется по умолчанию. Первый будет следить. Последний эквивалентен конвейеризации через tail.
(Чтение информации показывает, что журналы на самом деле должны находиться в /var/log/secure)