Linux 中是否有日志可以告知某些端口是否被拒绝

Linux 中是否有日志可以告知某些端口是否被拒绝

假设我已激活防火墙或任何其他安全措施,如 SE linux 等。

现在假设用户想要连接到端口21但 Iptables 不允许。

现在,当用户被拒绝时,该消息会被记录在任何地方,以便我可以看到特定使用的内容被阻止或特定端口被阻止的原因。

而不是深入挖掘每一个设置来找出为什么我无法通过它。

我已经将默认 ssh 端口更改为,8022但连接被拒绝。

我已经检查了 telnet 及其监听的端口。我的 iptables 为空。

有没有日志可以让我检查谁拒绝连接

答案1

第一个答案

没有。没有日志默认情况下,显示此内容,但是

显示当前防火墙配置

查看你的防火墙是如何配置的:

iptables -L

首先查找Chain [INPUT|OUTPUT] policy。如果除了 之外还有别的东西ACCEPT,那么使用过的端口可能必须经过ACCEPT彻底的清洗...

iptables -L INPUT | grep `port=2[01]`

显示有关端口 20 和端口 21 的明确规则,但请注意,您可能必须阅读整个防火墙配置,检查有关multiport、等。如果您完全user-defined chains不知道,这可能会变得困难。iptables

一个空的已打开防火墙配置可能如下所示:

iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

看:

man iptables

了解哪些内容可能会阻止你的规则

我使用了这个技巧:

touch /tmp/tmp_iptable_stat.txt
getChanges() {
    pushd /tmp >/dev/null
    for table in $(</proc/self/net/ip_tables_names);do
        echo $RANDOM: - $table
        iptables -t $table -nvxL --line-number
      done |
        diff -u tmp_iptable_stat.txt - |
        tee >(patch -p0) |
        sed '
            s/^+[0-9]*: - /TABLE /p;
            s/^+//p;
            d'
    popd >/dev/null
}

第一次调用getChanges将转储所有表和计数器。后续对同一函数的调用将仅打印修改计数器的规则。这可以帮助找出哪些规则正在阻止某些操作。

显示当前网络堆栈状态:

内核网络堆栈可以通过以下方式转储:

netstat -tan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN
tcp        0   2364 192.168.1.1:21          192.168.1.35:49179      ESTABLISHED

对于 TCP 套接字或

netstat -uan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      

用于 UDP 套接字。

作为我的FTP服务器使用TCP套接字,我可以看到一个交换当前已确立的在我的服务器和主机之间...35,(服务器当前有 2364 个数据包要发送给客户端。可能是文件,也可能是列表......)

跟踪特定接口上的流量

除了使用之外log,您还可以观察界面上发生的情况:

tcpdump -i ethX

这将转储有关流量的有用信息ethX,但默认情况下,人类可读,此工具将尝试解析每个 IP 的名称。因此,事件本身和终端上的转储之间可能会有一些延迟。所以:

tcpdump -ani ethX

不会尝试解析(opt -n)IP 和服务名称,并将显示-a穿过接口的所有()数据包。

更详细地讲:

tcpdump -ani ethX port 21 or port 20
09:17:58.264453 IP 192.168.1.1.21 > 192.168.24.91.45951: Flags [S.], seq 3593971599, ack 1942867644, win 5792, options [mss 1460,sackOK,TS val 1168768120 ecr 62841986,nop,wscale 7], length 0
09:17:58.299693 IP 192.168.1.35.56485 > 192.168.1.1.21: Flags [S], seq 3334605998, win 5840, options [mss 1368,sackOK,TS val 1936641509 ecr 0,nop,wscale 7], length 0
09:17:58.299728 IP 192.168.1.1.21 > 192.168.1.35.56485: Flags [S.], seq 980554936, ack 3334605999, win 5792, options [mss 1460,sackOK,TS val 1168768129 ecr 1936641509,nop,wscale 7], length 0
...

更详细:... use -v or -vv for full protocol decode

tcpdump -anvvi ethX port 21 or port 20
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
09:22:40.047486 IP (tos 0x0, ttl 62, id 31488, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.24.91.46011 > 192.168.1.1.21: Flags [S], cksum 0x5985 (correct), seq 3989081263, win 14600, options [mss 1368,sackOK,TS val 62912431 ecr 0,nop,wscale 6], length 0
09:22:40.047525 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.1.21 > 192.168.24.91.46011: Flags [S.], cksum 0x926d (correct), seq 2283473829, ack 3989081264, win 5792, options [mss 1460,sackOK,TS val 1168838566 ecr 62912431,nop,wscale 7], length 0
09:22:40.817248 IP (tos 0x0, ttl 62, id 31489, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.24.91.46011 > 192.168.1.1.21: Flags [.], cksum 0xd6e9 (correct), seq 1, ack 1, win 229, options [nop,nop,TS val 62912442 ecr 1168838566], length 0
09:22:40.817567 IP (tos 0x0, ttl 62, id 31490, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.24.91.46011 > 192.168.1.1.21: Flags [F.], cksum 0xd6e3 (correct), seq 1, ack 1, win 229, options [nop,nop,TS val 62912447 ecr 1168838566], length 0
...

您可以在其中跟踪每个操作。

答案2

如果禁用 iptables 和 SElinux,则可能没有日志可供读取。我不太明白 telnet 适合这种情况,因为它与 ssh 无关。当前的 SELinux 策略仅阻止 1023 以下非标准端口上的 ssh 连接,因此不太可能出现这种情况。

Connection refused消息通常意味着请求的端口上没有任何内容正在监听。您可以使用 netstat 检查是否有内容正在监听

netstat -tunlp | grep 8022
tcp        0      0 0.0.0.0:8022        0.0.0.0:*           LISTEN      2178/sshd
tcp6       0      0 :::8022             :::*                LISTEN      2178/sshd

以上显示 sshd 正在所有 IPv4 和 IPv6 接口上监听端口 8022。

答案3

如果你有日志在你的 iptables 规则上设置,那么你应该在 中获得一个日志条目/var/adm/messages。以下是一个例子:

# --- Log new connections:
-A INPUT -m state --state NEW -j LOG  --log-prefix "NEW: " --log-level info

您的 IP 表规则集中的如下规则可能可以帮助您入门:

# Enable port 8022 (ssh) but rate limit it:
-A INPUT -p tcp -m tcp --dport 8022 ! --syn -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8022 --syn -m limit --limit 3/minute -j ACCEPT

sestatus 命令将告诉您 selinux 是否已启用:

[root@seadog ~]# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted

默认情况下,来自 selinux 的消息会转到/var/log/audit/audit.log

semanage命令(在 rpm:policycoreutils-python 中找到)也可能有助于列出 selinux 正在控制的端口:

root@seadog log]# semanage port -l
SELinux Port Type              Proto    Port Number

afs_bos_port_t                 udp      7007
afs_client_port_t              udp      7001
afs_fs_port_t                  tcp      2040
afs_fs_port_t                  udp      7000, 7005
afs_ka_port_t                  udp      7004
afs_pt_port_t                  udp      7002
afs_vl_port_t                  udp      7003
agentx_port_t                  tcp      705

TCP 包装器也可能已启用。请检查/etc/hosts.allow/etc/hosts.deny文件。

在虚拟机中尝试这些功能是学习如何将所有内容整合在一起并在将规则投入生产之前建立信心的好方法。

答案4

它是

tcpdump -Ani ethX

不是

tcpdump -ani ethX

相关内容