Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Security Software Linux

Going Beyond Port Knocking; Single Packet Access 23

michaelrash writes "I have just released a new version of fwknop that implements a single-packet authorization scheme using libpcap (similar to what Simple Nomad has proposed for the upcoming BlackHat Briefings). Fwknop has made Slashdot once before as the first tool that combines port knocking and passive OS fingerprinting. However, this new single-packet method has many advantages over port knocking, including non-replayable messages, much more data can be sent (including complete commands), an attacker cannot break sequences simply by connecting to spurious ports on the target, and more. By using Netfilter to intercept packets within the kernel, anyone scanning for a service protected by this method cannot even talk directly to the IP stack without being authorized; that makes even 0-day exploits largely toothless."
This discussion has been archived. No new comments can be posted.

Going Beyond Port Knocking; Single Packet Access

Comments Filter:
  • Yeah, right. (Score:2, Insightful)

    by Anonymous Coward on Monday May 30, 2005 @08:23AM (#12675721)
    By using Netfilter to intercept packets within the kernel, anyone scanning for a service protected by this method cannot even talk directly to the IP stack without being authorized; that makes even 0-day exploits largely toothless."

    Yes, because we all know netfilter is invulnerable to 0days? No. [secunia.com]
  • by mnmn ( 145599 ) on Monday May 30, 2005 @09:59AM (#12676177) Homepage
    The client must know the combination to communicate at all. If the client is specialized, and trusted enough with the combination, why the heavy security? If we're dealing with public clients, they wont know how to port knock, at least the combination.

    In general if the TCPIP stack is clean and basic, along with a good packet filter ruleset (dont allow telnet), things will be pretty tough for a hacker. Why add overhead that makes the box secure only in theory (if that even).
  • by TheLink ( 130905 ) on Monday May 30, 2005 @12:58PM (#12677130) Journal
    Haven't there been security bugs with libpcap?

    If one rather not rely on libpcap being secure, one could whip up a perl/python server listening on some port, that'll handle the opening and closing of access to sshd and other stuff. That way you can use simple firewall rules which are less likely to have issues. Whatever it is you have to rely on the firewall code and kernel IP stack being secure.

    Sure it's an active server that's listening, but it's a lot easier to secure a perl/python program from buffer overflows and other exploits... You could still DoS it, but it's trivial to DoS the target's internet connection anyway.
  • by curunir ( 98273 ) * on Monday May 30, 2005 @03:41PM (#12678078) Homepage Journal
    My big question about port knocking is why use ports in the first place? Why not send whatever shared secret you're using in the header of the initial SYN packets? It would be just as secure (basically, horribly insecure) and wouldn't involve listening on extraneous ports.

    Why overload the port concept when there are plenty of better ways to send data?

Those who can, do; those who can't, write. Those who can't write work for the Bell Labs Record.

Working...