Half a croissant, on a plate, with a sign in front of it saying '50c'
h a l f b a k e r y
Contrary to popular belief

idea: add, search, annotate, link, view, overview, recent, by name, random

meta: news, help, about, links, report a problem

account: browse anonymously, or get an account and write.

user:
pass:
register,


                 

Please log in.
Before you can vote, you need to register. Please log in or create an account.

Stealth Web Server

 A personal web server that is hidden on the Internet
 
(0) 		  [vote for,
against]

(Caveat: Although I am a programmer, I have limited knowledge of networking protocols. So please keep that in mind while reading this)

I'm interested in the existence a personal stealth web server (PSWS).

The PSWS is a small web server that runs behind a firewall yet is externally accessible if you know the trick to access it. This will provide added protection for remotely accessing TivoWeb, web cams, and home automation. The goal would be to reduce the number of hacking attempts—especially automated attacks—on one’s private web server(s).

Consider that the PSWS user has a firewall is running in stealth mode. From my understanding this means that if another machine tries to connect to protected ports, there is no response and therefore the port doesn't even seem to exist.

The user would like to set up a web server on a non-standard port and make it available outside the firewall. However, he does not want the port to appear to be open unless the correct port and directory is requested.

For example, a request for http://www.foo.com:8073 would appear as if the port was not even enabled. On the other hand a request for http://www.foo.com/SECRET_DIR:8073 would successfully access a web page.

The obvious problems include the following:

1.) Any publicly accessible web access log might show a user accessing the secret directory. Search engines like Google might uncover this directory access.

2.) If someone was lucky enough to guess the directory, then they would have complete access to things you don’t want them to.

3.) I can only assume a tight integration between the network layers and the web server will be required for stealth operation whereas normally they would be separate.

Here are some potential solutions for the problems that I’ve raised:

1.) To counter the problem with the web access log, the secret directory would be ever changing. The secret directory could either be a function of the current time, or the user could carry around a time synched keychain password generator (such as used with high-end security systems). The password would be the necessary directory.

2.) The PSWS would not be the only security mechanism necessary to protect the web server. Additionally, security mechanisms such as password-protected SSL web pages and security logs would be necessary.

Has something like this already been implemented? Or are tools available that make this implementation trivial? I’ve tried searching the web but I’ve had no luck and I’m not sure what search terms I should be using.

Thanks for reading this! Any help would be appreciated.

—gonarch, Dec 01 2003

"Port Knocking" Discussion on /. http://slashdot.org...tml?tid=126&tid=172
[gonarch, Oct 04 2004]

[link]






       //assume a tight integration between the network layers and the web server will be required for stealth operation whereas normally they would be separate//
Certainly true, however for this to work as described you would require this integration at both ends of the link, which defeats the entire purpose.		   

       When you access a URL like "http://www.foo.com:8073/SECRET_DIR" the following steps take place:   

       (1) www.foo.com is resolved (usually via DNS) to a numeric IP address.
(2) A TCP connection is opened to port 8073 at that IP address
(3) An HTTP command of "GET /SECRET_DIR" is sent over that TCP connection
   

       The problem is you want the success or failure of step (2) to be decided depending on the contents of something that happens in step (3). Unless the client cooperates with you by sending the GET request in the initial connect TCP packet (this is legal, but not usually done), you can't make this happen.   

       What you need is something unique that can be sent during the initial TCP connect sequence that would notify the target host that you are you and not an attacker. TCP, like many IETF protocols, has an "options" capability that allows proprietary extensions to be added, perhaps you could implement it that way. The options could be exchanged during the initial connect sequence, thus falling entirely within step (2). I'm betting that a solution like that is baked, however.
—krelnik, Dec 01 2003
   

       You'd be better off doing the opposite. Have the web server respond to ALL connection attempts with a request for authentication. Only one port connection actually does anything, but hackers won't know which one.
—phoenix, Dec 01 2003
   

       Thanks for all the comments. I'm wondering if it would be good to combine your suggestions. Maybe have many ports that appear to be SSH port-forwarding ports but only have one that actually works?
—gonarch, Dec 02 2003
   

       Or just use IPSEC.
—krelnik, Dec 02 2003
   

       I added a link to a recent thread on Slashdot that discusses something very similar to what I was proposing. It's called "Port Knocking" and relies on a sequence of connection attempts to various ports in order to open the correct port.
—gonarch, Feb 05 2004
   

       Why not just put authentication on the ports? SSL maybe. Dont advertise your server, and if it is found (by bots and such trying random IP and ports), they will have to auth themselves. Problem solved. No need to hide it. Put up a Robots.txt just to be sure.
—excaliber, Feb 05 2004
   

       I would definitely still authenticate the ports somehow. The idea is to hide the fact that any particular port is open and also hide what protocol is running on that port. That way, you aren't immediately in danger of infiltration the next time an exploit is found.
—gonarch, Feb 05 2004
   
      
[annotate]
   


 

back: main index
business  computer  culture  fashion  food  halfbakery  home  other  product  public  science  sport  vehicle