Iptables rule to allow only one port and block others

Question

We have two apps running (on top of linux) and both communicates through port 42605. I wanted to quickly verify if this is the only port that's been used for communication between them. I tried below rule, but it doesn't seems to work. So, just wanted to get this clarified, if I am doing it wrong.

Following is the sequence of commands i ran

iptables -I INPUT -j REJECT
iptables -I INPUT -p tcp --dport 42605 -j ACCEPT
iptables -I INPUT -p icmp -j ACCEPT
iptables -I OUTPUT -p tcp --dport 42605 -j ACCEPT

So, this will get added in reverse order since I am inserting it.

I wanted to allow incoming and outgoing communications from and to 42605. Does the above rule looks good or am I doing it wrong?

Another question, would this be the right way to test, or maybe I should use "netstat" command to see which port has connection established with the other ip?

Solution

We can make INPUT policy drop to block everything and allow specific ports only

# allow established sessions to receive traffic
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# allow your application port
iptables -I INPUT -p tcp --dport 42605 -j ACCEPT
# allow SSH 
iptables -I INPUT -p tcp --dport 22 -j ACCEPT
# Allow Ping
iptables -A INPUT -p icmp --icmp-type 0 -m state --state ESTABLISHED,RELATED -j ACCEPT
# allow localhost 
iptables -A INPUT -i lo -j ACCEPT
# block everything else 
iptables -A INPUT -j DROP

Another question, would this be the right way to test, or maybe I should use "netstat" command to see which port has connection established with the other ip?

Yes, you can check netstat -antop | grep app_port and you can also use strace :

strace -f -e trace=network -s 10000 PROCESS ARGUMENTS

To monitor an existing process with a known pid:

strace -p $( pgrep application_name) -f -e trace=network -s 10000

Comments

[Admin]

Since you're just doing research, instead of doing a -j REJECT you should do a -j LOG. This is because REJECT will drop the packet and send back an ICMP destination unreachable packet to the affected client. LOG will just send the packet information to syslog (on most systems it ends up in /var/log/messages) then the packet is processed normally. So REJECT will likely break the application (at least temporarily) and you're at the mercy of what THAT causes the app to do, versus just logging the information and doing a tail -f on /var/log/messages