一部のポートが拒否されたかどうかを示すログがLinuxにありますか
ファイアウォールがアクティブであるか、SE linuxなどの他のセキュリティがあるとします。
ここで、ユーザーがポート21への接続を望んでいて、Iptablesがそれを許可していないとします。
ユーザーが拒否されると、そのメッセージはどこにでも記録されるので、使用されている問題がブロックされているか、または特定のポートがブロックされている理由を確認できます。
すべての設定を掘り下げるのではなく、なぜそれがうまくいかないのかを見つけます。
デフォルトのsshポートを8022に変更しましたが、接続が拒否されました。
私はtelnetとそのポートでの待機を確認しました。空のiptablesがあります。
誰が接続を拒否しているかを確認できるログはありますか
最初の答え
いいえ。デフォルトではlogはなく、これを示していますが、
現在のファイアウォール構成を表示しています
ファイアウォールの構成方法を確認してください。
iptables -L
最初にChain [INPUT|OUTPUT] policyを探します。 ACCEPT以外のものがある場合は、使用されているポートをACCEPTed泡にする必要があります...
iptables -L INPUT | grep `port=2[01]`
ポート20とポート21に関する明示的なルールを表示するには、ただし、注意して、ファイアウォール設定全体を読み、multiport、user-defined chainsなどを確認する必要がある場合があります。これを行わないと、困難になる場合があります。 iptablesをまったく知りません。
空のopenedファイアウォール設定は次のようになります：
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の最初の呼び出しよりも、すべてのテーブルとカウンターがダンプされます。同じ関数への後続の呼び出しでは、counterが変更されたルールのみが出力されます。これは、何かをブロックしているルールを見つけるのに役立ちます。
現在のネットワークスタックの状態を表示しています：
カーネルネットワークスタックは、
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 [〜 ＃〜]ソケット、1つの交換が現在サーバーとホスト間で確立されていることがわかりました... 35、（サーバーには現在、クライアントに送信する2364パケットがあります。おそらくファイル、おそらくリスト...）
特定のインターフェースでのトラフィックの追跡
logを使用する代わりに、インターフェースで何が発生するかを確認できます。
tcpdump -i ethX
これはethXのトラフィックに関する有用な情報をダンプしますが、デフォルトでより多くhumain判読可能になるため、このツールは解決を試みます各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
...
各操作を追跡できる場所。
Iptablesルールに[〜＃〜] log [〜＃〜]が設定されている場合、/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 Wrapper も有効になっている可能性があります。 /etc/hosts.allowおよび/etc/hosts.denyファイルを確認します。
これらを仮想マシンで試してみると、ルールを本番環境に導入する前に、すべてを組み合わせて自信をつける方法を学ぶことができます。
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で待機していることを示しています。