Is there any logs in Linux which tells if some port has been denied
Solution 1:
First answer
No. There is no log by default, showing this, but
Showing current firewall configuration
Look how your firewall is configured:
iptables -L
Look for Chain [INPUT|OUTPUT] policy first. If there is anything else than ACCEPT, used port may have to be explitely ACCEPTed lather...
iptables -L INPUT | grep `port=2[01]`
To show explicites rules about port 20 and port 21, but care, you may have to read entire firewall configuration, to check about multiport, user-defined chains, etc.. this may become hard if you don't know iptables at all.
An empty opened firewall config could look like:
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
see:
man iptables
Knowing what could block something in your rules
I use this trick:
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
}
Than a first call to getChanges will dump all tables and counters.
subsequents calls to same function will print only rules where counter are modified. This could help to find which rule are blocking something.
Showing current network stacks state:
The kernel network stack could be dumped by
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
for TCP sockets or
netstat -uan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
for UDP sockets.
As my FTP server use TCP sockets, I could see that one exchange is currently established between my server and host ...35, ( the server has currently 2364 packet to send to client. maybe a file, maybe a list... )
Tracking for traffic on specific interface
Instead of using log, you could watch what's happen on your interface:
tcpdump -i ethX
This will dump usefull information about traffic on ethX, but as by default and to be more humain readable, this tool will try to resolve each IP's name. So there may be some delay between the event himself and the dump on terminal. So:
tcpdump -ani ethX
won't try to resolve (opt -n) IPs and services names and will show ALL (-a) packets traversing the interface.
more finely:
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
...
More detailled: ... 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
...
Where you could follow each operation.
Solution 2:
With iptables and SElinux disabled there will likely be no logs to read. I don't quite understand where telnet fits into this scenario as it has nothing to do with ssh. Current SELinux policy only blocks ssh connections on non standard ports below 1023 so it's unlikely to be that.
The Connection refused message usually means that nothing is listening on the requested port. You can check if something is listening using 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
The above shows that sshd is listening on port 8022 on all IPv4 and IPv6 interfaces.
Solution 3:
If you have LOG set on your iptables rule then you should get a log entry in /var/adm/messages. Here is an example:
# --- Log new connections:
-A INPUT -m state --state NEW -j LOG --log-prefix "NEW: " --log-level info
A rule like below in your IP tables ruleset might get you started:
# 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
The sestatus command will tell you if selinux is enabled:
[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
The messages from selinux go to /var/log/audit/audit.log by default.
The semanage command (found in rpm: policycoreutils-python) might also be useful to list which ports selinux is controlling:
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 might also be enabled. Check for /etc/hosts.allow and /etc/hosts.deny files.
Trying these things out in a virtual machine is a great way to learn how to put it all together and build confidence before putting your rules into production.