Date: Fri, 22 Aug 2008 08:58:28 +0200 From: Jan Stary <hans@stare.cz> To: Ross Wheeler <rossw@albury.net.au> Cc: Mikhail Teterin <mi+mill@aldan.algebra.com>, Jeremy Chadwick <koitsu@freebsd.org>, freebsd-security@freebsd.org Subject: Re: machine hangs on occasion - correlated with ssh break-in attempts Message-ID: <20080822065828.GA28155@www.stare.cz> In-Reply-To: <20080822074020.G32956@ali-syd-1.albury.net.au> References: <48ADA81E.7090106@aldan.algebra.com> <20080821200309.GA19634@eos.sc1.parodius.com> <48ADCFD5.8020902@aldan.algebra.com> <20080822074020.G32956@ali-syd-1.albury.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 22 07:48:13, Ross Wheeler wrote: > On Thu, 21 Aug 2008, Mikhail Teterin wrote: > >>Surely you don't have that many users who SSH into the NAT router from > >>random public IPs all over the world, rather than via the LAN? Surely > >>if you yourself often SSH into your NAT router from a Blackberry device, > >>that you wouldn't have much of a problem adding a /19 to the allow list. > >>That's a hell of a lot better than allowing 0/0 and denying individual > >>/32s. > >> > >Myself -- and the owner of the box -- travel quite a bit, ssh-ing "home" > >from anywhere in the world. Although we could, I suppose, find out the > >destination-country's IP-allocation and add it before leaving, that would > >be quite tedious to manage... > > One of my clients used to have a microwave link from my network to their > office - and they were totally paranoid about remote access yet needed > live IPs fr other reasons. > > They too needed frequent remote access from arbitary addresses. > > I overcame these conflicting requirements with a 2-step process. They > "authorised" user first browsed to a website which asked their username > and password. When entered correctly, it opened a hole in the firewall to > allow that IP to their network. A timer ran every 15 minutes to close the > hole (but was over-ridden by the web page which kept refreshing every 10 > mins). The last part may not be necessary for you, but this may be a > possible workaround for your traveling access. Leave a default of deny any > except from trusted, fixed hosts, and add transient access as required. Eh? Sounds like a web-based reimplementation of authpf. Jan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080822065828.GA28155>