[clug-talk] Port Knocking?
curtis.sloan at shaw.ca
Tue Jan 11 11:27:50 PST 2005
On Tue January 11 2005 03:06, bogi wrote:
> Hi Shawn.
> port knocking will only delay a pro for a few hours at best, than they will
> authenticate and get the data. Not very useful in your case. Having
> mentioned the end users using laptops, this brings up a big (commy) red
> flag. What if the laptop is allready stolen ??, browser caches checked,
> data and passwords taken. Using a vpn with a single-use-password system
> combined with a fully encrypted filesystem on the laptops would be a far
> better solution than monkeying around with port knocking and whatnot.
> On January 11, 2005 02:09, Shawn wrote:
> > Hoping someone can help me out.
> > A client has a web application that they want to make accessible to their
> > employees via the web (of course). The catch is that the app has
> > critical business data that CANNOT become available to script kiddies
> > and/or the competition. (There is a login routine, via the database, but
> > I don't trust that on it's own with this data).
> > So, the options as I see them are to use a VPN solution only, bring in an
> > SSL certificate and use HTTPS (though this doesn't really stop the script
> > kiddies - just sniffers), or maybe use port knocking.
> > When I explained port knocking, the client seemed rather keen (even
> > though I told him it's a relatively new technology). The questions I
> > have to find out now is what it would take to get this set up, in such a
> > way that field users can connect via their laptops. Does anyone have any
> > experience with Port Knocking? I know enough to know what it is, but
> > that's about it.
> > Or would this situation be best suited to a VPN?
As Szemir pointed out, there is no one single security product or feature that
will make all data/communications secure.
Port knocking is more "security through obscurity" than anything. It simply
masks the presence of a application with a secret handshake. It would be
more crucial, IMHO, to ensure that data stream and communication process was
A VPN creates a secure tunnel to back-end servers (i.e. LAN access over the
Internet). Since this is a web app, that's probably overkill (a VPN just for
a browser-to-web server transaction). So, yeah, SSL is probably the standard
implementation of choice for this scenario (unless I'm missing something).
Perhaps others will have some insight into best practices for this type of
situation that I lack.
A layered security approach is implemented in the various different areas you
expose along the way. For instance, you should have your web server in a
DMZ. Your web server should be secured according to best practices. Sane
firewall rules should be in place (e.g. egress filtering). A general
security policy framework should be in place for monitoring, auditing and
dealing with security-related events. You might eventually add port knocking
in for kicks, but it's only going to complicate matters which increases
support. If you've got the rest taken care of already and you want the extra
layer of protection (and the resulting trade-off in simplicity/usability),
then by all means go ahead.
Security is a large, open-ended, constantly changing landscape that requires
attention from end-to-end in order to be successful. Frankly, it means a lot
of work, and the business decision whether to support it lies in the balance
of the investment in time/money/effort/etc. vs. the relative value of the
corporate assets at stake, such as corporate data.
Sorry to turn this into a small dissertation on Information Security
practices, but from my standpoint (as a security/privacy advocate) once you
open up the can of worms that is "security", you're forced to deal with all
of it (to varying limited degrees).
More information about the clug-talk