Testing egress network access

One of the ways one can test outbound or egress firewall rules is a tcp connection test.

I recently discover portquiz.net. Port Quiz is an outgoing port tester and gives connection examples for various clients, telnet, powershell, nc (netcat), curl, wget, etc… I’ll use PowerShell in my example below.

Why would you need to use this, a recent example that we had was - is that we had some SIP phone users that had some connection issues - as the first step was to see if tcp/5060 (SIP) was accessible from their soft-phones. Was it blocked by their ISP? or some other issue?

Portquiz to the rescue:

1
PS>Test-NetConnection -InformationLevel detailed -ComputerName portquiz.net -Port 5060

egressInternet

For example, SIP is blocked from this machine and they needed to check with their ISP for further troubleshooting.

Portquiz is a handy internet facing website that listens on all ports and allows for egress network testing.

localtunnel - quickly expose a local webserver to the world

localtunnel is a pretty neat tool. It solves the problem of quickly exposing a web server to the internet without messing with deploying to a “test server” messing with a router/firewall and NATing/PortForwarding. It works like this, assuming you have a webserver listening on port 8080 dbergert$ localtunnel -k ~/.ssh/id_rsa.pub 8080 This localtunnel service is brought to you by Twilio. Port 8080 is now publicly accessible from http://52rq.localtunnel.com ... Now browse to the URL and there is your publicly exposed webserver for that quick show or test. More on localtunnel on its github page: https://github.com/progrium/localtunnel

SSL / VPN / Direct Connection connecivity options

I came across this exchange discussing connectivity when reviewing some specifications for an interface that we are writing:

“Since both companies will utilize web services for the exchange of information, it is proposed that we use SSL instead of a VPN or Direct connection. SSL (https over port 443) provides security by encrypting the communications channel. This arrangement provides all the security of a VPN or Direct connection. Plus it requires less network configuration, less maintenance, greater flexibility (in case platforms move on either end) and eliminates a VPN or direct connection as a potential point of failure.”

I have a lot of problems with this.

1) Encryption isn’t security.

2) I find it hard to dispute that: Direct Connection > VPN > SSL over internet from a general security perspective.

3) SSL used in this manner lacks authentication, compared to a IP SEC point-to-point VPN (AH/ESP)

4) Exposing a web server to the internet introduces the risk of web server vulnerabilities, application layer vulnerabilities, among others ever more recent SSL vulnerabilities[1]. (Note that source based ACL’s are not recommend here either, nor are client side certificates for authentication)

5) The concept of “least privilege” from a networking perspective is not followed - only two parties need to talk to each other, why open it up to the world to attempt to connect to ? Another interface stated “We restrict all traffic by third party connections to the least access needed to support business. “ <– I like this much better.

6) SSL over the internet will require our customer to expose a secure internal system to the internet, when it was designed to have very controlled network access, as compared to a VPN and general firewall rules for network control.

7) I haven’t discussed direct connections or leased lines, mostly due to the nature and volume of this application. Normally this is our first choice for high volume, sensitive transaction data to third parties with multiple data centers. Where we use 2 leased lines on different carriers to different data-centers.

My Vote for this? SSL over a VPN - (Defense in depth) Could SSL be used ? Sure but we would need to add a list of controls around its implementation and quite possibly add a layer of applications (proxy the requests) to design around this which is more work and has a higher change of configuration failure then a standard site-to-site VPN connection.

[1] http://www.theregister.co.uk/2011/04/11/state_of_ssl_analysis/print.html

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×