4

Somehow I have been charged with the task of organizing the installation of a new production environment involving 4 servers.

I have to make requests to the Network administrator to open up ports on the firewall. He says he has made the changes and I need to check them.

I need to check that:

1 server alpha will be able to SFTP to server beta.

2 server alpha will be able to connect to LDAP on server gamma 636.

3 server alpha will be able to view webservices on server delta port 80

The best way I know how to do this is to try to telnet to the server, so for example for situation #1 I tried logging into alpha and :

alpha> telnet beta.mycompany.com 22

Is there a better way to test if I can connect on ports 22, 636 and 80?

1
  • Do the damn thing! SFTP from alpha to beta. Setup LDAP from alpha to gamma. Hit the website from alpha on delta.
    – dmourati
    Nov 26, 2020 at 4:20

3 Answers 3

3

Assuming that the services are "listening" on the destination servers using a TELNET client to test TCP connectivity is a perfectly valid method. You can use a tool like "netcat" if you want to get even more bare-bones. You're just testing up the stack to TCP this way. You can't guarantee that the layer 7 protocol is actually working w/o doing more.

If you want layer 7 verification, use a client program for each of the protocols in question and attempt to perform some type of client / server interaction from the machines that will be sourcing the connections.

As always, if you're in doubt about whether your traffic is making it where you'd expect it to go I'd recommend using a sniffer (tcpdump, Wireshark, etc) to verify that the packets really are ending-up where you expect them to. There's no substitute for watching the bits on the wire.

2

It really depends on what level of verification you're looking for. For most simple single port TCP services (such as those listed), you just need to verify that the port is open and accepting connections. The easiest method would be to use nmap. Specific syntax for checking the ports mentioned would be:

nmap -p 22,80,636 192.168.1.1

And would return a result along the lines of:

Starting Nmap 5.00 ( http://nmap.org ) at 2011-01-24 16:20 CST
Interesting ports on 192.168.1.1:
PORT    STATE  SERVICE
22/tcp  open   ssh
80/tcp  open   http
636/tcp closed ldapssl

Nmap done: 1 IP address (1 host up) scanned in 0.23 seconds

If the firewall were blocking any of those ports, the STATE returned would be filtered instead of open or closed.

That only verifies the firewall rules, though. It doesn't verify that the service is necessarily running on the port, or that it is operating correctly. For that, you'd have to run a check that understood the service you were checking.

1

this is an old question, but if anyone needs to do a test of their firewall, I wrote a tool called fcat (firewall cat), its used to open up a range of ports on server A

on Server B, you can use fcat to connect to that range on A and see which ports are being blocked by the firewall

the reason I created it, is because you can easily scan for open ports with nmap, but I couldnt find an easy way to spin up port listeners without using some sort messy bash loop

Fcat

https://github.com/perfecto25/fcat

fcat makes this much simpler,

examples,

on Host A

hostA> fcat -p 1500,1900,21000-21500  (will open ports 1500,1900 and every port in 21000-21500 range)

# can also bind to specific IPs or iface names
hostA > fcat -p 2000,3400-3500,27000-27150 -i 192.168.35.2 
hostA > fcat -p 2000,3400-3500,27000-27150 -i em1

on Host B

hostB > fcat conn -h hostA -p 21000-21500 (will test basic TCP connection to this port range)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .