I'm wondering what are the relative risks of the different ports I have opened up on my firewall.
Currently the ports I have open are:-
22 - ssh (but limited to only allowing two IP addresses to connect) 80 - http 25 - smtp 873 - rsync (not sure if I actually use this now, must check!)
I'm considering what the risks of opening up port 443 (https) are to use with shellinabox and ssh. This would allow ssh from a web browser anywhere into my desktop machine (in addition to https access to the apache server of course), is this a significantly bigger risk than the limited ssh access that I have now?
My thinking is that the port 443 access to ssh *is* significantly riskier than my existing ssh access, however I'm not sure if I'm being overly paranoid given that I already have open access on port 80 to my web server.
What I'm really asking is whether worrying about open ssh access (with a good secure password) is a bit irrelevant given that port 80 is open to web browsers? Or is the damage that could be done if someone *does* guess my password (or it gets out by some other means, quite possible) for ssh much worse than anything using a browser/apache exploit?
Any/all help appreciated, including ways that I could limit the shellinabox access to specific clients. As it is the client I'm thinking of is my Kindle but nothing at the shellinabox end can see anything to do with the Kindle because the proxying in between effectively anonymises the connection.
On 20/11/11 11:48, Chris Green wrote:
I'm wondering what are the relative risks of the different ports I have opened up on my firewall.
Any/all help appreciated, including ways that I could limit the shellinabox access to specific clients. As it is the client I'm thinking of is my Kindle but nothing at the shellinabox end can see anything to do with the Kindle because the proxying in between effectively anonymises the connection.
One thing you might consider doing is using fail2ban with a slightly modified ruleset.
By default it looks at the ssh logs and adds a firewall rule on the ssh host to block any ipaddress that has say 5 authentication failures for a pre-set period of time.
With some modifications to the easily rewritten rules you could have it do the same thing for failed authentication via shellinabox.
As to limiting what clients can connect...you could probably do it badly via the kindle's user agent string...or even though it is proxied you could allow/deny ipblocks...but be aware that these are likely to change when your kindle roams.
As to the other ports there is no excuse for having a bare rsync port as any rsync transfers over an untrusted network should be wrapped up in ssh...but we have argued about this before :)
On Sun, Nov 20, 2011 at 11:28:03PM +0000, Wayne Stallwood wrote:
On 20/11/11 11:48, Chris Green wrote:
I'm wondering what are the relative risks of the different ports I have opened up on my firewall.
Any/all help appreciated, including ways that I could limit the shellinabox access to specific clients. As it is the client I'm thinking of is my Kindle but nothing at the shellinabox end can see anything to do with the Kindle because the proxying in between effectively anonymises the connection.
One thing you might consider doing is using fail2ban with a slightly modified ruleset.
By default it looks at the ssh logs and adds a firewall rule on the ssh host to block any ipaddress that has say 5 authentication failures for a pre-set period of time.
That's a good idea, thanks.
With some modifications to the easily rewritten rules you could have it do the same thing for failed authentication via shellinabox.
As to limiting what clients can connect...you could probably do it badly via the kindle's user agent string...or even though it is proxied you could allow/deny ipblocks...but be aware that these are likely to change when your kindle roams.
Yes, that's the problem, I'm only likely to use the Kindle for E-Mail when I'm somewhere outlandish and don't have a laptop with me.
As to the other ports there is no excuse for having a bare rsync port as any rsync transfers over an untrusted network should be wrapped up in ssh...but we have argued about this before :)
I think, as I said, that's no longer in use so I'll take it out. I seem to remember it was used with an 'rsync server' set-up.
-
Chris Green -
Wayne Stallwood