4

Suppose in i have the firewall active or any other security like SE linux etc.

Now suppose user wants to connect to port 21 and Iptables does not allow it.

Now when users gets denied is that message logged any where so that i can see what the partucular used is blocked or why particular port is blocked.

Rather than digging every setting to find out why i am not getting through it.

I have chnaged the default ssh port to 8022 but i am getting conenction refused.

I have checked telnet and its listening on that port. I have empty iptables.

Is there any log where i can check who is refusing connection

  • the selinux is enabled? – ALex_hha Jul 22 '13 at 5:42
  • @ALex_hha SeLnux is disabled – MOtaro Site Jul 22 '13 at 5:49
  • Can you ssh to localhost on port 8022? And you said you have empty iptables - that means - all connections will be blocked by default. You need to allow connection to port 8022. – Muhammad Jul 22 '13 at 5:52
  • @Muhammad how can i disable iptables completeley to check that – MOtaro Site Jul 22 '13 at 6:03
  • service iptables status and service iptables stop – davey Jul 22 '13 at 6:16
8

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.

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.

  • ha ha , sorry by telnet i mean netstat. i had iptables running but there was no rules there, i then stopeed it and then i was able to connect. how can i allow 8022 – MOtaro Site Jul 22 '13 at 6:12
  • @MOtaroSite: man iptables is your friend. – Iain Jul 22 '13 at 6:22
  • @MOtaroSite, I've updated my original answer with an iptables example rule but as Iain says you should definitely use the man pages. – davey Jul 22 '13 at 7:07
2

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.

  • i have read that if iptables is empty it means everthing is allowd. because then how can i connect to port 22 if everything is blocked . no i have no tcp wrappers – MOtaro Site Jul 22 '13 at 6:02
  • What does the selinux audit log say? – davey Jul 22 '13 at 6:10
  • Also check Iain's suggestion (can you clear up the confusion on telnet vs. sshd?) – davey Jul 22 '13 at 6:12
  • tail -f /var/log/audit/audit.log and then attempt your ssh connection, see what appears. – davey Jul 22 '13 at 6:13
  • i dont have any audit dir in log. i have se linux disabled – MOtaro Site Jul 22 '13 at 6:27

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.