ways/tools to check for ports required by applications to facilitate firewall rules creation

sunhux G sunhux at gmail.com
Mon Aug 11 04:11:09 UTC 2008


Firstly any equivalent of Solaris'  snoop &  truss command in Linux?

We ran into this problem from time to time :

the outsourced vendors/support staff (like application developers, CA
Unicentre monitoring team
member) would request our firewall administrator to permit certain Tcp/Udp
ports to be pass
through the firewall/Cisco switch.

Problem is :
the vendor/support staff themselves are often not 100% certain which Tcp/Udp
ports their
applications require & if the ports used by returning traffic comes through
high ports (source
& destination ports issue)

Our firewall admin is green & would only do just the firewall permissioning.
 I have no access
to the firewall & the firewall admin told me the Sidewinder/Borderware do
not have logs which
could give us any clue as to what Tcp/Udp ports the application is
attempting to connect through
or return traffic uses.

Let's assume the firewall/Cisco network admin is not going to help.

Is there anything I can do on the source & destination servers to establish
which ports
are required?  On Linux OS level (of the source server), I thought of
issuing
   netstat -an 1 | find "source_or_destination_IP_address"
& then on the source server, launch the application/command to make the
connection &
the continuous "netstat" would reflect which port it's attempting to connect
through.

For successful connections, "netstat -an" would show the status as
"ESTABLISHED"

However, for Udp ports, don't think it will be shown as "ESTABLISHED", am I
right? as
Udp is connectionless protocol??

Any script (that's rapidly/continously running) or free tools that I can run
on the source &
destination servers that could help me determine which ports are the servers
attempting
to connect to ?

Suppose the firewall admin finally allows me to gain a brief access to the
firewall's Unix
command line, what command I can issue to find out the tcp ports, if any ?

Very often, there's return traffic too & this needs to be sniffed out too,
eg:
passive ftp initiated on Tcp port 20 from source & think high port needed
for return traffic
ftp data used Tcp 21 (believe if it's get, it would be from destination to
source while
   if it's put, it would be from source to destination??)

My all time favorite in the days I'm a firewall admin is to create a
universal rule(s) which
permit all Tcp/Udp ports between the source/destination & issue "netstat -an
| grep addrs"
on both source/destination, remove the universal rule &  then create more
restrictive rule(s).



More information about the redhat-list mailing list