Ned Slider wrote:
> Daniel Swid wrote:
>> Hi,
>> Was following along reading your how-to with a box I had ssh'd to. I
>> started
>> pasting in the commands to build my own filter and my computer
>> connection
>> suddenly stopped responding after I pasted in
>>
>> iptables -P INPUT DROP
>>
>> Thought it'd be good of you to add a little warning next to that
>> line....
>>
>> Cheers,
>> Daniel
>>
>
> Hi Daniel,
>
> Thanks for your comments and you raise a good point. I'll look to
> adding a comment to address that issue.
>
> I guess the best solution would be to develop and test your script
> locally before uploading and deploying on a remote server.
> Alternatively, if you must test remotely, setting up a cronjob to
> deactivate the firewall after 5 mins is a popular approach to prevent
> locking yourself out of your machine (if anyone on the list has any
> thoughts about this, it would be appreciated??)
Oh, yes, please add a note about "at now + 5 minutes pretty please
disable firewall". It's simple, effective, useful. Safety nets are needed.
As I had my fair part of cutting my access to remote machines via "well
designed" firewall rules, I have settled for the following
- whitelist the IPs I connect from at the very beginning of the firewall
script
- rather than rely on default policy being DROP, I prefer to let it on
ACCEPT but end the script with:
echo log stuff
$IPT -A FORWARD -j LOG --log-prefix "blocked in forward "
$IPT -A INPUT -j LOG -m limit --limit 20/m --log-prefix "blocked in
input "
$IPT -A OUTPUT -j LOG -m limit --limit 20/m --log-prefix "blocked in
output "
echo almost fascist drop
$IPT -A FORWARD -j REJECT
$IPT -A INPUT -j REJECT
$IPT -A OUTPUT -j REJECT
Ned: I suggest to insert a line after the "-P DROP" to warn people that
this command will cut access from remote sites unless a previous ACCEPT
rule already exists. . So either upload and test a full script, or work
locally.... or take care :)
