3 ms·
Well, that's omitting the rules required to get an SSH packet to that chain. I also hope you've already ACCEPTed ESTABLISHED,RELATED so we're only considering t
by ohboyacomment 14y ago
Well, that's omitting the rules required to get an SSH packet to that chain. I also hope you've already ACCEPTed ESTABLISHED,RELATED so we're only considering these rules on new connections, otherwise you've entirely locked out SSH after the third packet.
Assuming that's true, now guess what happens when you do this during a crisis:
for i in backup-file-{0..999}; do
scp $i that-machine:/var/db/
done
Unless you're muxing in your local SSH config, you will cause the firewall to intervene on you during the absolute worst time, and you will have no idea why. Promise.
I really wish we could reverse the trend of fiddling with iptables when it comes to SSH. Everybody does it and nobody thinks about the ramifications.
- jrabone 14y agoOP didn't ask for a complete firewall script, and besides they should be writing their own rather than copy-pasting the whole thing. Of course there's more to it. The global limit on scp is fine; this is an internet-facing server with minimum user data for which I have a cold spare - there's nothing to back up. You're coming over like you're the only person in the world who knows what they're doing; might want to rethink that.
- tomp 14y agoYou're right, I didn't think it through... So, is there any way (in your opinion) how one can safely retain password access for root/one user, so it's still possible to control the server, even if you don't have your keys?
- asb 14y agoYou are totally right, and it seems non-trivial to work around this. One approach would be to whitelist an IP upon successful logon. Perhaps by modifying /etc/ssh/sshrc to invoke iptables (though this is not executed as root...). An alternative would be to use pam_exec and have that invoke iptables to whitelist the IP (assuming it can find out the IP). But I don't think PAM is even used if SSH private key authentication is used...