Hi James,
Cheers dude, I have the usual suspects protecting SSH: fail2ban (on 3 unsuccesful attemps and blocked for 24hours), Snort (with the appropriate plugin running to attach to IPtables and block any suspicious activity) SSH Config: root login disabled and approved users only / no password entry (just public keys)
Can I ask though, why is it a bad idea to have a script running as root? accordingly, fail2ban runs in this way, and of course many other daemons, so long as it is only executable etc by root, and has no "interface" surely it's secure?
Thank for the info on subnets, this will definitely provide a temporary work around, at the moment I am half way through writing a node module that is currently detecting SSH logins and logging the info required by iptables, I just need to integrate this https://github.com/pkrumins/node-iptables module, and I will be able to edit iptable rules; but as you have suggested this needs to be executed as root (and i'm almost certain running a node instance as root is a dodgy activity); I cannot beleive there is not an exisiting "secure" script on ubuntu that I can manipulate to acheive my needs
SSH Tunnels are probably the way to go with it; I'm trying to simplify something that is already pretty simple by the looks of the responses :)
I dunno, maybe I should give up with the obsession :) hehe
Cheer and a Merry Christmas to you all
Alex
On Thu, Dec 22, 2011 at 1:46 PM, James Bensley jwbensley@gmail.com wrote:
On 20 December 2011 21:56, Alex Scotton alex.scotton@gmail.com wrote:
I don't want to limit the connections to SSH or change the SSH port, I would like it so that upon a successful connection to the SSH Daemon (i.e. someone authenticates with their public key) that their IP address is added to IPTables to allow access to the port range 7000-7999.
Hey Dude,
I don't think having a script run post SSH authentication is a good idea as it's going to need root access (just my two pence).
Instead, what I have on a home server is some slightly loose rules. Set your sshd config to not allow root access, only your two user accounts, have crazy complex non-dictionary passwords, disconnect after 3 bad logins etc. All the usual gaff.
Then, the following iptables rules will block an IP that is brute forcing your sshd but allow your specified users; #Block automated SSH attacks iptables -N SSHSCAN iptables -A INPUT -s 1.2.3.4/32 -p tcp -m tcp --dport 22 -j ACCEPT iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSHSCAN iptables -A SSHSCAN -m recent --set --name SSH iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j LOG --log-level info --log-prefix "SSH SCAN blocked: " iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j DROP
I've allowed SSH access for my known good IP, 1.2.3.4. You could add few loose rules in for your remote friend. Get his WAN IP and look it up with a whois lookup, find the subnet/ip block its part off and add that subnet as an allowed IP range. This will cover 99% of your friends IP changes strait of the bat. The odds of another broadband customer on your friends ISP in the same subnet attacking your box are 1 in a ga-jillion (real number!) so I think it's an acceptable risk (which should be balanced by the previously mentioned long passwords and no root logins etc).
Also, have you thought about SSH tunnels? You could just open SSH access, then you can your friend can tunnel in to the other ports you mentioned?
Ts & Cs: I'm some what hung over so this may not be the best advise :S
-- James. http://www.jamesbensley.co.cc/
main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!