> > > > Well thank you for that. I had planned on setting up port > > > > knocking for ssh and cups but I guess I'm just as well off > > > > leaving them listening on 22 and 631? > > > > > > Fail2Ban, though a little intensive, seems to be a decent method for > > > avoiding unwanted SSH traffic while accepting trusted traffic. I > > > have seen one deployment where it seems passably inconspicuous, at > > > least. > > > > > > Alternately, if you run SSH on an unusual port, you're unlikely to > > > see much Bot traffic. I would recommend this, if you're concerned, > > > above port knocking myself -- relying on a complicated > > > "pre-authentication" method rather than / in addition to a remote > > > admin tool like SSH seems to be asking for problems. > > > > Do you mean problems in the form of hassles? > > Yeah, hassles and potential misconfiguration, because if anything goes > wrong (rookie admin messes up knocking, for instance, on the > server/firewall) you can't log in from home and fix it, you have to > drive all the way out there to get in from the other side. > > Port knocking seems like a decent security method to me, especially if > it was running on the firewall and opened ports only to the knocking IP > -- in that case, it certainly wouldn't be obvious to any other computer > that the port had been opened. > > However, I tend to think it is more trouble than it's worth, and has a > tendency to make people think that they can be lazy about security > because 'intruders would have to port knock anyway'. I tend to prefer > strong firewalls, strong passwords, and, potentially, RSA certs or > something to _really_ make sure. > > > So you're saying ssh > > running on an unusual port is good enough? > > I'm no expert, but from my logs: SSH attempts (from bots in Shanghai > and the like) on port 22 number in the thousands, unexpected SSH > attempts on the nonstandard ports I run SSH on (actually it's > firewall-level port forwarding) have not yet been logged. > > It's kind of an "obscuring for security" argument, but I think it's a > good balance between goofy port knocking setups and just running plain > old SSH on 22. > > Of course, Nothing is a replacement for strong password enforcement, > and if the systems are important, I would probably require certificates > as well. > > And again, I stress that I'm no expert. I have been using nonstandard > ports and the Bots seem none the wiser, but I can still log in on those > ports from any computer without having to aquire and configure port > knocking clients.
Sounds like I should forget port knocking and set up RSA certificates. > > > > As for printing from lpr to cups across the internet, I should be > > > > encrypting that data shouldn't I? Nothing too sensitive but it > > > > sounds like a good thing to do. It looks like cups can use ssl > > > > but I don't see any mention of it in man lpr. > > > > > > SSH Tunneling and VPN come to mind too, but I must ask - what good > > > is printing a physical document across the net, unless the printer > > > is still only a little way away, and if so, what is it doing behind > > > a public network? I am curious about this deployment. > > > > I'd be happy to tell you more but I'm not sure what you mean. "Still > > only a little way away"? > > > > Thinking of all the times I printed something, I cant think of many > situations when I didn't have to walk over to the printer after > printing, grab the printout, and carry it to the intended destination. > > I can imagine situations where you'd want to print invoices and the > like at front offices or even remote storefronts and locations, but > wouldn't you want a VPN up between your remote offices anyway? That's more or less what I'm trying to do. Is setting up a VPN between my remote server and local network overkill? I think the only thing I'd use it for is to hide the sending of these printouts. - Grant -- gentoo-user@lists.gentoo.org mailing list
