Fundacja Rozwoju Regionu Gołdapedukacja techniczno informatyczna
Access:

» Port knocking from the inside out

Related categories: Port knocking | Networks

Martin Krzywinski
Viewed: 27172 | Article date: 2006-02-24 11:41:35

Leaving a port open to the public is like an invitation for an intruder. Unfortunately, most services such as HTTP or SMTP need to be open for everyone to see. However, some of the more critical services may be accessible only when required. Here's where port knocking comes in.

 

About the author

Martin Krzywinski (http://mkweb.bcgsc.ca) is a bioinformatics research scientist. He works with fingerprint maps of large genomes and loves to write Perl scripts of all sizes. He has a background in *NIX system administration and system automation. He is originally from Warsaw, but now lives in Vancouver, Canada where he kayaks and drinks a lot of espressos.

 

 

Leaving a port open to the public is like an invitation for an intruder. Unfortunately, most services such as HTTP or SMTP need to be open for everyone to see. However, some of the more critical services may be accessible only when required. Here's where port knocking comes in.

If we are running strongly-authenticating network services (e.g. SSH) on our server, it is likely that we are using the service's authentication and encryption process to discriminate between legitimate and illegitimate users. The legitimate user has a password and the illegitimate user does not. In order for the service to establish this fact, the illegitimate user is offered a chance to interact with the service.

Given that password guessing methods offer little chance of penetrating a well-maintained system, an intruder will try to bypass the authentication component of the service and try to elevate their privileges by exploiting a known bug, such as a buffer overflow. Since a zero-day exploit that targets our service may appear any day, maintaining a network service is not a passive activity. We must monitor vulnerability advisories and keep an eye out for patches to plug new security holes. But let's face it - reading advisories is boring, thankless and 99.99% of the time uninformative. It may be a year or two, or never, before an exploit for our version of a service is found and reported. So what can we do?

First, let's consider the fact that services with an finite user base do not need to have their ports open at all times. Unlike public services such as SMTP or HTTP, which need to receive connections from anyone and anywhere and usually do not require authentication, SSH is one such service which permits only password-bearing users in. Now, imagine being able to keep the SSH port (tcp/22) closed, thus making the service inaccessible and protected from exploits, until the service is actually requested by one of our legitimate users.

 

What you will learn...

  • what port knocking is, how it works and what it's used for,

  • how to write the simplest implementation of port knocking,

  • how to set up the Doorman program for advanced port knocking,

  • how port knocking can be detected and compromised.

 

What you should know...

  • you should be familiar with the basics of TCP/IP networking,

  • you should posses basic Linux administration skills.

 

 

But how is this service requested if ports are closed and no connections are possible? This is where port knocking comes in. Port knocking permits a user to request for a port to be opened in front of a network service. This request takes the form of a passive sequence of authentication packets across closed ports on the server (see Inset Port knock - information across closed ports). It is possible to send information across closed ports, even if the ports are closed and no network services are listening, because our firewall or another utility like tcpdump can be configured to monitor all incoming packets, even if they never reach an application like SSH.

 

 

Limitations of IP filtering

One way to limit the cross-section of our network service is to use an IP filter (see Inset IP filters), like netfilter/iptables. The filter would be configured to only allow connections from IP addresses from which our user base is connecting. This list would include remote offices and homes.

This approach does well to limit the number of sources from which connections are allowed, but is limited in its ability to deal with mobile users or offices/homes for which external IP addresses are dynamically assigned. If our users frequently change computers or networks, it may not be practical to maintain a changing list of IP addresses from which connections are permitted. This is especially true when users try to connect from notoriously untrustworthy locations like Internet cafes or university laboratories.

Using an IP filter makes the assumption that behind a trusted IP address, or network address, are only trusted users. This is clearly not always true, especially when the trusted IP address is a gateway of a large internal network. It's easy to imagine a case in which attacks and legitimate connections originate from the same IP.

 

Port knock - information across closed ports

Contrary to common opinion, we do not need open ports to transmit data. Even if connections are denied by an IP filter, these attempts are logged and therefore can be mined for information.

In the simplest case, let's consider ports A and B which are both closed, with no associated listening application. If the IP filter is configured to monitor packets arriving at these ports then it is straightforward to parse out the filter logs and identify the port sequence (e.g. ABAAABBAA) associated with a client IP. This port sequence can be used to encode information. The encoding could be a map between a specific port sequence and piece of information (e.g. ABA = open port 22 for 15 minutes, ABB = close port 22, BAA = close port 22 and do not permit additional connections). The encoding could also be binary with A/B representing 0/1.

 

Page: 1 2 3 4
Buy article Buy subscription
Buy now add to cart
add to cart
Standard price: 2€/$2 Standard price: 25€/$30
Buy article for as little as (2€/$3) each allow access to individual articles. Buy a full access to our Hakin9 archive portal. You will be able to read the articles from all archive issues from year 2005 and 2006. For just 25€/$30 you get unrestricted access to the entire website for the whole year.
SDJhakin9

.SDJ Users:


.:Login
.:Password

[Register]
[Forgotten your password?]

...hakin9 StarterKit IT Practical Solutions for Newbies

...Shopping Cart

sum: 0 €
Choose currency:

...SUBSCRIBE TO
hakin9 Print Edition


...Advertisement



...Conferences

...Topics

...Advertisement

 

 

Subscribe | Contact Us | Newsletter | See all issues | About Hakin9
Copyright C 2006 by Software Developer's Journal. All rights reserved.