OpenBSD Journal

Alternative to Port-Knocking using OpenBSD PF + OSFP

Contributed by J. Webb on from the os-fingerprint-not dept.

This might be interesting for some folks. 
poplix@papuasia.org has written up an interesting proof-of-concept 
for an alternative to port-knocking type solutions which basically 
employs PF's support of OSFP-based rulesets along with a userland util.
for modifying IP header values etc.

From writeup:

"The idea is to use os fingerprints as a key. An user can invent a
 specific sequence of header values that will identify his fake os,
 add it to fingerprints database and use it in the firewall.
 The result is an OBSD machine that is totally stealth to port scans
 but the owner can log into it using his specific set of header values."


Full details are here:
http://tripp.dynalias.org/p0fspoof.txt

(Comments are closed)

Comments

  1. By Alex Holst (80.160.149.62) on

    When will people get that "port knocking" is just another plain text password?

    Skilled attackers (who are able to find new bugs in your OS and running services) can get around something like this. Script kiddies can't get in unless the admin is completely incompetent.

    So why bother?

    If the log messages from script kiddes are bothering you, teach your log analyser to ignore those specific ones.

    Comments

    1. By Anonymous Coward (69.70.207.240) on

      It's just an added layer of security and it most certainly does have it's uses and advantages. Sure some can get by this, but some others can't. Why make life easier for them? Besides, if you don't like it, don't use it - simple as that...

      Comments

      1. By Paladdin (213.97.233.52) on

        The question here is there's no a new security layer at all. No crypto == No security.

        Good security policy would never assume that a hacker will not sniff your packets -In fact, if he can, he will!-.

        Defending from script kiddies with scripts-kiddies-like stuff is a nice game, but it makes no security at all.

    2. By Anonymous Coward (208.38.59.80) on

      *sigh*, just another point of failure ..

    3. By Anonymous Coward (129.215.16.39) on

      Not all forms of port knocking are insecure:

      http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-worth-up.pdf
      This paper describes an implementation of port knocking that uses
      the same principle behind one time passwords in order to render
      sniffing "cleartext" knocking sequences useless.

  2. By m0rf (68.104.17.51) on

    for a second i thought it was ospf, not osfp, which would have been more interesting.

  3. By Anonymous Coward (68.106.232.57) on

    It would be nice if the people who claimed "this is another layer of security" actually had an idea of what security meant.

    Just because you can throw another thin film of plastic your "layers of security" doesn't mean it'll amount to a hill of beans when you're trying to protect your system. What happens the first time you send your secret fingerprint to the remote system? The packets can be captured and the fingerprint replayed. Game over.

    Don't bother with this if you're interested in securing your system. It is a proof of concept. Clever, but of limited utility.

    We've been around this carousel before with the locking down SSH bit. Don't run sshd on a different port of what you want is *security*. Tighten the reins on your sshd by implementing strong authentication. Firewall it if you can. Certainly rate limit connections so bruteforcing is more difficult. Don't think you're gaining anything by obfuscating. You don't understand the real threats, and you're misleading yourself. It works if you're trying to protect yourself from talentless kiddies. Why don't you do something that protects your system from knowledgeable attackers? Do that and you'll thwart the kiddies at the same time. Brilliant, really.

    And if the noise in your logs irritates you, analyze your logs differently. /usr/bin/less isn't doing the trick for you.

    Comments

    1. By Anonymous Coward (69.70.207.240) on

      Crude example: - You need access to sshd from *anywhere*; you tighten everything down as much as possible. A.) You rely just on what you've done to tighten it down and the latest patches. B.) Use the above + you make life more difficult for those who know how and make it not possible for those who don't know how (to capture the fingerprint and re-play). Some will manage to know you have sshd running, others will think it's not and move on elsewhere... You limit more attempts (which can be successful or not) by adding this on top of your existing layers of security. How many more compromise attempts can you avoid? Anything more is good. There is no harm in adding another layer like this. Infact, I think it's brilliant; but by no means not the be it end all to security, obviously. No one is arguing saying this is the ultimate security solution; who needs to tighten their systems when there's this... LOL

      Comments

      1. By Anonymous Coward (206.132.94.6) on

        Why, because they haven't posted to this thread yet?

        Yes, they are out there. They're the ones who post responses to "helpes!!! i`m beinG hakced by lots of peoples!" with things like "use portknocking" or "run your_service_here on a different port" instead of things like "choose strong passwords and don't log in from untrusted locations" or "blow away password auth and use something that provides stronger authentication like s/key or pubkey".

        The concept is best practice. Do something that has utility and doesn't hinder your normal way of getting in to the system unreasonably. Gidgets and gadgets and neat one-offs like this impose an unproportional amount of overhead to your setup compared to the miniscule amount of real-world "security" that they provide.

        Comments

        1. By Anonymous Coward (12.18.141.172) on

          And don't forget that 'AllowUsers' is one of your best friends. In addition to everything above. With regard to the rest Amen, brother. I get way tired of seeing alternate ports touted as a "security" measure for all the reasons you mention above.

          Comments

          1. By Anonymous Coward (205.240.34.148) on

            Except automated sweeps of a specific port for a specific service will be thwarted. The would be attacker doing the sweep, compentent or not, will move on to the exposed systems he finds, probably never batting an eye at you false negative.

            True, there is no real security through obscurity. But, obscurity and security can send a would be attacker in circles, frustrating his efforts, and tying up his resources. They even make software called "honeypots" just for this purpose.

            It's all like putting up a fence around your yard. There are many people who can climb a fence, but not many will. Many people will move on just because you have the fence.

            Essentially what you, and everyone else like you, is saying to those who try to bait, confuse, or otherwise mislead an attacker is that you don't need the fence when you have bars on the windows.

            When it comes to security, every little bit helps.

          2. By Anonymous Coward (128.171.90.200) on

            I guess that is why the OpenBSD approach is not to shut down services, but make the services hard to break.

  4. By Evan Farrer (12.191.193.67) Evan.Farrer+obsd@gmail.com on http://www.cs.utah.edu/~farrer/

    There have been several people that have pointed out that port-knocking like approaches are simple plain text passwords, or security through obscurity. The counter argument is that "every little bit helps". I think that there is a falacy in the "every little bit helps" counter argument in that it assumes that port-knocking adds some security with *no* negative consequences. The proponents of port-knocking seem to assume that the port-knocking system won't have any flaws. What if the software has a security flaw? Buffer overflow, accidentally exposes private information, etc. It adds one more service that needs to be audited. What about the time that it takes to set up the system, could your time be better spend? Are we focusing on the "little bit" when there are much larger vunerabilities? Evan

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]