Re: Suggestion for a new feature, port code
we will never let that shit even remotely close to our tree. period. * Johan Söderberg johan.s.u...@gmail.com [2011-03-04 15:00]: In my mind this is not security by obscurity, no more than one-time passwords. The ports can be compared to the keys of a keyboard when typing a password. As with passwords, the implementation is not a secret. The port that is protected is not hidden, it is locked. It adds security and do not add attack vectors as it is implemented as a simple ruleset for pf, protecting sshd. It can also be combined with authpf. Why waste energy on spammed logs with scans and attacks, banning and luring with honeypots on the outside? Why give sshd unnecessary exposure as it may have weaknesses? http://en.wikipedia.org/wiki/Security_through_obscurity http://stackoverflow.com/questions/4486171/isnt-a-password-a-form-of-security- through-obscurity http://security.stackexchange.com/questions/1194/port-knocking-is-it-a-good-idea -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: Suggestion for a new feature, port code
Henning Brauer henning at openbsd.org writes: we will never let that shit even remotely close to our tree. period. we don't need you to tell us that as that shit already works. full stop.
Re: Suggestion for a new feature, port code
2011/2/28, Karl O. Pinc: If you want it to be secure you make the knock code a ome-time-pad. 2011/3/1, me: If I change the knock ports every time I log in, I should be fine, right? Nah, still vulnerable to MITM. Just intercept and stop the knocks from reaching, and replay them yourself. But it needs to be planned. So it's still worth changing knocks.
Re: Suggestion for a new feature, port code
A quick google on 'pf port knocking' turned up the following that might be of interest. http://www.lazyscripter.com/2010/04/port-knocking-with-pf/ On Feb 28, 2011, at 10:17 AM, Johan Söderberg wrote: A ridiculously simple idea. Protect your port, say ssh, by adding a code to access it. Ok, that's nothing new, but maybe how it's done. For a client to connect to a service, it need to unlock the port with a code. The code is made of predefined blocked ports, that makes pf trigger. If the first code port is triggered, IP address enters a state with timestamp. If the next port that the address triggers, matches the next code port within a timeframe, let it enter new state, else lose state. When all code ports have been triggered in the right order, allow address to pass. Sure it's not safe from MITM, but it protects from scans, and allows you to connect from dynamic IP addresses. There are 65536 ports, that gives you 65536^n possible combinations where n is the number of ports in your code. So you probably won't need more than 2-3 ports in your code. Say what you think! And if you like my brain fart, would you want to implement it? Kind regards, Johan Söderberg
Re: Suggestion for a new feature, port code
Johan Söderberg johan.s.u...@gmail.com writes: For a client to connect to a service, it need to unlock the port with a code. The code is made of predefined blocked ports, that makes pf trigger. You have just described 'port knocking'. It's been discussed in PF contexts before (I forget which lists, could have been openbsd-misc or here), and the conclusion was roughly that it doesn't add much in terms of security, certainly not worth the potential added complexity. The enthusiasts tend to live on Linux, IIRC. There are 65536 ports, that gives you 65536^n possible combinations where n is the number of ports in your code. So you probably won't need more than 2-3 ports in your code. That's almost like saying, my password's written with unicode, so 2-3 characters is fine. To my mind, that's all the added security you get, roughly equivalent to a password. It's a well known fact that industrial-scale password guessing is going on right now, so once the bad guys figure out the obvious, the machinery to crack your box is ready to go. Add to that the typical implementation scenario with a deamon that reads your firewall logs for your secret sequence and all its possible failure modes (a full disk will brick your box, as will any exploitable bug that with a potential to kill your daemon, and so forth). Oh well, that's just a small sample of what the sceptics here will say. I've been meaning to get around to a proper treatment of port knocking in a blog post or article, and that may still happen given enough round tuits. In the meantime, the main points have already been presented. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Suggestion for a new feature, port code
On Mon, February 28, 2011 10:17 am, Johan Söderberg wrote: A ridiculously simple idea. Protect your port, say ssh, by adding a code to access it. Ok, that's nothing new, but maybe how it's done. For a client to connect to a service, it need to unlock the port with a code. The code is made of predefined blocked ports, that makes pf trigger. If the first code port is triggered, IP address enters a state with timestamp. If the next port that the address triggers, matches the next code port within a timeframe, let it enter new state, else lose state. When all code ports have been triggered in the right order, allow address to pass. Sure it's not safe from MITM, but it protects from scans, and allows you to connect from dynamic IP addresses. There are 65536 ports, that gives you 65536^n possible combinations where n is the number of ports in your code. So you probably won't need more than 2-3 ports in your code. Say what you think! And if you like my brain fart, would you want to implement it? Also known as 'Port Knocking': http://en.wikipedia.org/wiki/Port_knocking I recall it was discussed here a while back. I can't recall what the exact arguments were, but I don't suppose it'd be hard to write a userland daemon to implement it using anchors. Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ---
Re: Suggestion for a new feature, port code
spamassassinexception Thank you so much for your input! If I change the knock ports every time I log in, I should be fine, right? Please comment on my ruleset, brain fart again? knock1 = 1 knock2 = 2 open = 22 block drop in all block drop quick on $extif inet proto tcp \ from any to $extaddr port $knock1 \ tag knock1 block drop quick on $extif inet proto tcp \ from any to $extaddr port != $knock2 \ tagged knock1 tag knock block drop quick log on $extif inet proto tcp \ from any to $extaddr port $knock2 \ tagged knock1 tag knock2 block drop quick log on $extif inet proto tcp \ from any to $extaddr port != $open \ tagged knock2 tag knock pass in quick log on $extif inet proto tcp \ from any to $extaddr port $open \ modulate state (max 1) \ tagged knock2
Re: Suggestion for a new feature, port code
On 02/28/2011 09:17:25 AM, Johan Söderberg wrote: A ridiculously simple idea. Protect your port, say ssh, by adding a code to access it. Ok, that's nothing new, but maybe how it's done. For a client to connect to a service, it need to unlock the port with a code. The code is made of predefined blocked ports, that makes pf trigger. If the first code port is triggered, IP address enters a state with timestamp. If the next port that the address triggers, matches the next code port within a timeframe, let it enter new state, else lose state. When all code ports have been triggered in the right order, allow address to pass. Sure it's not safe from MITM, but it protects from scans, and allows you to connect from dynamic IP addresses. There are 65536 ports, that gives you 65536^n possible combinations where n is the number of ports in your code. So you probably won't need more than 2-3 ports in your code. Say what you think! And if you like my brain fart, would you want to implement it? Your idea is called port knocking, and it's pointless security by obscurity -- and can be sniffed. If you want it to be secure you make the knock code a ome-time-pad. In which case you may as well use skey for your one-time-pad and be done with it. If you want to protect the port redirect repeat offenders off into a honeypot. Karl k...@meme.com Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein
