New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Trying to chmod and run a shell script at startup
JohnMiller92
Member
I am not sure if I am doing this correctly. But i've spent over 2 hours and and don't understand why it's not working.
rc.local:
#!/bin/sh -e
chmod +x /root/startup.sh && /root/startup.sh
exit 0
startup.sh:
#!/bin/bash
/sbin/iptables -A INPUT -p TCP --syn --dport 80 -m recent --set
/sbin/iptables -A INPUT -p TCP --syn --dport 80 -m recent --update --seconds 10 --hitcount 10 -j DROP
In fact, the chmod does work correctly on reboot
, however the startup.sh doesn't get executed. Any help / insight is appreciated!
Comments
Any reason not to use iptables-persistent? You could also just put the iptables command right in the rc.local file.
But since you're clearly trying to rate-limit a web connection, most web servers have that built in. The advantage of using the web server is that the client will actually get a proper HTTP response code and so therefore know to slow down.. versus your setup which makes it look like your site is broken.
Usually Id put the script I wanted to start at boot in /etc/init.d and/or /etc/rc.local . You might wanna try that.
Oh yeah. Forgot about that :P. I'll just do that for now. I was just using a iptables snippet I found online, still havn't honed in on what limits I should do. I, ideally want to drop everything except inbound/outbound on ssh, port 80, and 9300. And limit new connections to them, maybe with connlimit or something too. Thank you btw
Not sure on how you are "sure" the chmod works correctly but here are a few hunches/ideas:
1) Not sure what distro and init system you are using. Iptables has issues when run in parallel with other iptables commands due to some locking issues. This is typically seen in systemd type setups.
2) Try putting in a big sleep (like 30s) before the iptables commands and see if that helps.
3) Put in a few (benign) debug thingies in your startup.sh script (like touch /something-somewhere) to see (after boot) how it is sequenced based on the timestamps.
Hopefully one of the above will give you clue on what is going on and you can solve the issue.
Of course I'm assuming that after boot if you manually run the startup.sh file everything works fine :-)
It's unclear to me why you won't just save your iptables rules. If you have reasons to be really concerned about syn and if you're really sure your webserver won't handle it properly, check the SYNPROXY target (if available for you). I'd avoid handling a physiological event (a connection to a public webserver, as opposed to e.g. a connection to an ssh port clearly not meant for public) with the recent module, as it has its set of limitations. Consider jumping to the DROP target (maybe not even in the filter table if we're thinking of a possible attack) as a last resort for what has to be considered a set of otherwise physiological events; possibly try at least to use a more polite REJECT first (with tcp-reset or not, depending on what we're talking about)
Also, use /bin/sh directly, and set your environment explicitly.
PATH=/bin:/sbin:/usr/bin:/usr/bin..
What distro is it? That might be a place to start.
My bet is that chmod is failing as it isn't explicitly called, and who knows what 'sh -e' is inheriting.. since he called &&, it evaluates to false.
Unless you know systemd which ignores a bunch of stuffs.
Technically, it did/does/may support rc.local. It did on Debian 8.