|
||||||||||
Ok - I've read the articles... why is this better than say an arbitrary web script over https that allows the remote user to implement whatever firewall mods are permissable? The only time I can see benefit to this concept would be where NO services were open to the world at all I guess... but if anything is going to be running already than you are already at risk through those services - may as well use them to manage your ports... Am I missing something? With the difficulty involved in sending the knock (considering remote users having to carry around removable media arbitrarily executable knock scripts to unknown environments with unknown execution options) it seems to be an elite feature suitable only for more versed power-user / sysadmin types... Don't get me wrong - I can appreciate innovation for it's own sake - you have to try things to see if there is value in them sometimes - but what's the value to the average user - how usable would it be? A simpler concept might just be to allow public port mappings (after authentication) from the initiating IP... for example - I need to get access to an internal server from wherever I am - VPN won't work because of hotel router idiocy, etc.... I go to https://myhomegateway:customport/secretadminscript/ and click the "open terminal server to remote host for X minutes" An inbound forwarding rule is created, and destroyed on inactivity or timeout. Just a thought. m/ > -----Original Message----- > From: Jason P Jones [mailto:jjones at integracon dot com] > Sent: Friday, February 06, 2004 9:53 PM > To: Adam Nellemann > Cc: m0n0wall List > Subject: Re: [m0n0wall] Port Knocking? > > > I would think that an excellent place for this in code- that would be > very usable, would be an option for VPN initialization. Could be an > option in setup for new VPN connections with a port sequence of the > user's choice (say a limit of 5 or so for the sequence) and possibly a > user definable time. Again, just a good option for this or some other > offshoot project. Everyone wants features, few want to code them or > worry over the size they add. This could probably be done in a few KB > though (an yes I wish I was the one with the time and ability to knock > it off). > > Jason P Jones > > > On Sat, 2004-02-07 at 00:14, Adam Nellemann wrote: > > Nice idea, I like it! > > > > It probably should be elaborated on a bit (as suggested in some of the > > articles) to prevent easy detection of a "knock" taking place (a nice > > alternative, which could also be elaborated on and/or combined with the > > usual "knock": http://doorman.sourceforge.net) > > > > I guess a "test" implementation could be done with no changes to > > m0n0wall, simply by making a small daemon running on a machine > recieving > > syslog messages from m0n0wall and using http to make the changes to the > > rules (assuming this can't be done more easily in other ways, such as > > SNMP or..?) > > > > Of course a usable implementation should either reside completely on > > m0n0wall, or depend on a better way to monitor the filter log > and change > > the firewall rules from a local machine running the "knocker daemon". > > > > Adam. > > > > Don Gray wrote: > > > > > Anyone read these articles? Any ideas how to implement with > m0n0wall/IPFilter? It's an interesting concept. > > > > > > http://slashdot.org/article.pl?sid=04/02/05/1834228&mode=thread&tid=126&tid= 172 > > http://www.linuxjournal.com/article.php?sid=6811&mode=thread&order=0 > > http://www.portknocking.org/ > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch > For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch > --------------------------------------------------------------------- To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch |