I learned how to configure and deploy an application server the hard way (some say, the proper way), because I had to do it over a command-line console. Yes, a web visual interface is available, but the port it's running on is behind several of the firewalls, and there are no other well-known unused port numbers I can run the service on. Saturday morning musing...?
Three years ago I wrote a patch for SSHD that a paranoid network admin (or any paranoid single-server owner) can deploy on their Linux machines to track exactly which terminal host a remote user logs in from, rather than the immediate host. (Actually, not quite the terminal host, but the last unpatched machine outside his network)
Some would argue of course, "If I'm not allowed to log-in to the DMZ host from my home PC, how'd any sysadmin do their jobs from home?" (I did mention upfront that it is for the paranoid, and therefore, will often stand on the way of the practical!) Specifically, this patch would protect against hosts in the 'grey area' (not quite trusted as in the DMZ, but not quite untrusted either—example: campus network)
Now I have a new problem: tracing firewalls. Often, my servers sit behind several subnets' firewalls: one on the machine itself, one of the immediate subnet, and maybe one more, that of the ISP's. For a development server, many ports often need to be opened to the public. Now, how does one know which firewall blocks which port? I need a traceroute-like utility (for *NIX OSes) that can track which ports are being blocked at which subnet... If anybody knows, please write me, else it's another project in the works :)
No comments:
Post a Comment