see tcpdump and strace On Mon, 2008-08-11 at 12:11 +0800, sunhux G wrote: > 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). -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
