Debian iptables on boot
Hello,
I am new to Debian with some experience on Centos. I am trying to configure iptables for Debian to start on boot. I have iptables intstalled and my iptables.rules file is located in /etc. I was reading several things about putting in softlinks in the init.d or rc3.d to get iptables to start on boot. Could someone point me in the right direction, everything I have tried so far I cannot get iptables to survive the reboot. Here is the rules I have listed. # Written by Robert Penz <robert.penz@outertech.com> # This script is under GPL 2 or above # # Ideas and parts from # Christophe Grenier <grenier@cgsecurity.org> # Olivier Boudeville <olivier.boudeville@online.fr> # # To debug this kind of firewall script, one may use : # sh -x /path/to/this/file # Useful with 'iptables --list' or 'iptables -L -n |more' to check # whether rules are up-to-date : rules_version=1 # full path of the programs we need - changed them to your needs iptables=/sbin/iptables modprobe=/sbin/modprobe echo=/bin/echo # Load appropriate modules. $modprobe ip_tables # we load that modules as we want to do statefull firewalling $modprobe ip_conntrack $modprobe ip_conntrack_ftp # These lines are here in case rules are already in place and the script is ever rerun on the fly. # We want to remove all rules and pre-exisiting user defined chains and zero the counters # before we implement new rules. $iptables -F $iptables -X $iptables -Z # Set up a default DROP policy for the built-in chains. # If we modify and re-run the script mid-session then (because we have a default DROP # policy), what happens is that there is a small time period when packets are denied until # the new rules are back in place. There is no period, however small, when packets we # don't want are allowed. $iptables -P INPUT DROP $iptables -P FORWARD DROP $iptables -P OUTPUT DROP ## ============================================================ ## Kernel flags # To dynamically change kernel parameters and variables on the fly you need # CONFIG_SYSCTL defined in your kernel. I would advise the following: # Enable response to ping in the kernel but we'll only answer if # the rule at the bottom of the file let us. $echo "0" > /proc/sys/net/ipv4/icmp_echo_ignore_all # Disable response to broadcasts. # You don't want yourself becoming a Smurf amplifier. $echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts # Don't accept source routed packets. Attackers can use source routing to generate # traffic pretending to be from inside your network, but which is routed back along # the path from which it came, namely outside, so attackers can compromise your # network. Source routing is rarely used for legitimate purposes. $echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route # Disable ICMP redirect acceptance. ICMP redirects can be used to alter your routing # tables, possibly to a bad end. $echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects # Enable bad error message protection. $echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses # Turn on reverse path filtering. This helps make sure that packets use # legitimate source addresses, by automatically rejecting incoming packets # if the routing table entry for their source address doesn't match the network # interface they're arriving on. This has security advantages because it prevents # so-called IP spoofing, however it can pose problems if you use asymmetric routing # (packets from you to a host take a different path than packets from that host to you) # or if you operate a non-routing host which has several IP addresses on different # interfaces. (Note - If you turn on IP forwarding, you will also get this). for interface in /proc/sys/net/ipv4/conf/*/rp_filter; do $echo "1" > ${interface} done # Log spoofed packets, source routed packets, redirect packets. $echo "1" > /proc/sys/net/ipv4/conf/all/log_martians # Make sure that IP forwarding is turned off. We only want this for a multi-homed host. $echo "0" > /proc/sys/net/ipv4/ip_forward ## ============================================================ # RULES ## First rule is to let packetes through which belong to establisted or related connection # and we let all traffic out as we trust ourself. $iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT $iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # ---------------- INPUT --------------------- ## Log some invalid connections : $iptables -A INPUT -m state --state INVALID -m limit --limit 2/ -j LOG --log-prefix "[#$rules_version : invalid input : ]" $iptables -A INPUT -m state --state INVALID -j DROP ## Avoid stealth TCP port scans if SYN is not set properly : $iptables -A INPUT -m state --state NEW,RELATED -p tcp --tcpflags ! ALL SYN -j DROP ## FRAGMENTS # I have to say that fragments scare me more than anything. # Sending lots of non-first fragments was what allowed Jolt2 to effectively "drown" # Firewall-1. Fragments can be overlapped, and the subsequent interpretation of such # fragments is very OS-dependent. # I am not going to trust any fragments. # Log fragments just to see if we get any, and deny them too. $iptables -A INPUT -f -j LOG --log-prefix "[#$rules_version : iptables fragments ] : " $iptables -A INPUT -f -j DROP ## auth/ident #if we drop these pakets we may need to wait for the timeouts # e.g. on ftp servers $iptables -A INPUT -p tcp --dport 113 -m state --state NEW -j REJECT --reject-with tcp-reset ## http stuff #$iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT #$iptables -A INPUT -p tcp --dport 443 -m state --state NEW -j ACCEPT ## ftp #$iptables -A INPUT -p tcp --dport 21 -m state --state NEW -j ACCEPT ## ssh # This rules allow to prevent brute-force SSH attacks by limiting the # frequency of attempts : # Logs too frequent attempts tagged with 'SSH' and drops them : $iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --name SSH -j LOG --log-prefix "[#$rules_version : SSH brute-force ] : " $iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --name SSH -j DROP # Tags too frequent SSH attempts with the name 'SSH' : $iptables -A INPUT -p tcp --dport 22 -m recent --set --name SSH # Accepts nevertheless normal SSH logins : $iptables -A INPUT -p tcp --dport 22 -j ACCEPT ## mail stuff #$iptables -A INPUT -p tcp --dport 25 -m state --state NEW -j ACCEPT #$iptables -A INPUT -p tcp --dport 110 -m state --state NEW -j ACCEPT #$iptables -A INPUT -p tcp --dport 143 -m state --state NEW -j ACCEPT #$iptables -A INPUT -p tcp --dport 993 -m state --state NEW -j ACCEPT #$iptables -A INPUT -p tcp --dport 995 -m state --state NEW -j ACCEPT ## DNS server # Allow UDP&TCP packets to the DNS server from clients. (only needed # if this computer is a DNS server) #$iptables -A INPUT -p tcp --dport 53 -m state --state NEW -j ACCEPT #$iptables -A INPUT -p udp --dport 53 -m state --state NEW -j ACCEPT ## LOOPBACK # Allow unlimited traffic on the loopback interface. # e.g. needed for KDE, Gnome $iptables -A INPUT -i lo -j ACCEPT $iptables -A OUTPUT -o lo -j ACCEPT # ---------------- ICMP --------------------- # all can ping me - remove that line if no one should be able to ping you $iptables -A INPUT -p icmp --icmp-type ping -j ACCEPT # ---------------- LOGGING ------------------- # log every thing else, up to 5 packets per min #$iptables -A INPUT -m limit --limit 5/minute -j LOG I just want to open ssh for the time being. Thanks, Keith |
You might try iptables-save and iptables-restore as a starting point. Here is a link that might be of some help:
http://iptables-tutorial.frozentux.n...#IPTABLES-SAVE I believe on Debian there is a default setup file that has some useful information, I think this file is located as follows: /etc/default/iptables Read it for some helpful instructions. Regards, Fordeck |
Quote:
All I want open is ssh. I saved my rules in /root/iptables-save.out # Generated by iptables-save v1.3.6 on Sun Dec 7 01:31:00 2008 *filter :INPUT ACCEPT [9516:685061] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [6712:445334] -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT COMMIT # Completed on Sun Dec 7 01:31:00 2008 I created a script and put it in the /etc/network/if-pre-up.d/iptables My script is as such #!/bin/sh # Load iptables rules before interfaces are brought online # This ensures that we are always protected by the firewall # # Note: if bad rules are inadvertently (or purposely) saved it could block # access to the server except via the serial tty interface. # RESTORE=/sbin/iptables-restore STAT=/usr/bin/stat IPSTATE=/root/iptables-save.out test -x $RESTORE || exit 0 test -x $STAT || exit 0 # Check permissions and ownership (rw------- for root) if test `$STAT --format="%a" $IPSTATE` -ne "600"; then echo "Permissions for $IPSTATE must be 600 (rw-------)" exit 0 fi # Since only the owner can read/write to the file, we can trust that it is # secure. We need not worry about group permissions since they should be # zeroed per our previous check; but we must make sure root owns it. if test `$STAT --format="%u" $IPSTATE` -ne "0"; then echo "The superuser must have ownership for $IPSTATE (uid 0)" exit 0 fi When I reboot I can ssh into the box from another location fine. When do iptables --list all I get is Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination My rules are not there but yet I can ssh into this box, I am confused? Thanks again, Keith |
Hi,
why don't you put your firewall script in /etc/rc.local? Quote:
|
iptables survive reboot
Quote:
I have my rules saved at /root/iptables.rules.2 echo "#!/bin/sh" > /etc/rc3.d/iptables echo "iptables-restore < /root/iptables.rules.2" >> /etc/rc3.d/iptables chmod +x /etc/network/if-up.d/iptables These were the instructions I was trying to follow to survive the reboot. I changed from /etc/network/if-up.d/iptables to /etc/rc3.d/iptables either way it does not work after reboot the rules are not loaded when iptables --list. Any suggestions would be appreciated. Thanks again Keith |
Hi,
Try to look for errormessages in /var/log/messages and dmesg Perhaps the rules are loaded before the network is connected. This could make the rules not to load. |
iptables script
Hello,
I over looked a very important fact which is I did not have a script to use for iptables so this is what I have now. #!/bin/sh # Load iptables rules before interfaces are brought online # This ensures that we are always protected by the firewall # # Note: if bad rules are inadvertently (or purposely) saved it could block # access to the server except via the serial tty interface. # RESTORE=/sbin/iptables-restore STAT=/usr/bin/stat IPSTATE=/etc/iptables.rules test -x $RESTORE || exit 0 test -x $STAT || exit 0 # Check permissions and ownership (rw------- for root) if test `$STAT --format="%a" $IPSTATE` -ne "600"; then echo "Permissions for $IPSTATE must be 600 (rw-------)" exit 0 fi # Since only the owner can read/write to the file, we can trust that it is # secure. We need not worry about group permissions since they should be # zeroed per our previous check; but we must make sure root owns it. if test `$STAT --format="%u" $IPSTATE` -ne "0"; then echo "The superuser must have ownership for $IPSTATE (uid 0)" exit 0 fi # Now we are ready to restore the tables $RESTORE < $IPSTATE This script I placed in /etc/network/if-pre-up.d My iptables.rules is in /etc/ Rules follow as such # Generated by iptables-save v1.3.6 on Mon Dec 8 04:43:03 2008 *filter :INPUT ACCEPT [2256:256923] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [1063:171796] -A INPUT -s 192.168.2.101 -d 24.24.5.73 -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -s 172.34.5.8 -j DROP -A INPUT -s 67.215.66.132 -d 192.168.2.103 -p tcp -m tcp --dport 25 -j REJECT --reject-with icmp-port-unreachable -A INPUT -d 192.168.2.103 -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -d 192.168.2.103 -p tcp -m tcp --dport 25 -j ACCEPT -A INPUT -d 192.168.2.103 -p tcp -m tcp --dport 20:21 -j ACCEPT -A INPUT -d 192.168.2.103 -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -d 192.168.2.103 -p tcp -m tcp --dport 443 -j ACCEPT -A INPUT -s 127.0.0.1 -d 192.168.2.103 -j ACCEPT -A INPUT -d 192.168.2.103 -p icmp -j ACCEPT -A INPUT -j REJECT --reject-with icmp-port-unreachable -A FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -j REJECT --reject-with icmp-port-unreachable -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT COMMIT The script is chmod +x chown root.root iptables.rules is owned by root also. I know its something with the script or where im placing it, I can't figure it out. Thanks again, Keith |
Hi,
When you execute the script, does it work at that moment? If yes, put a line like /path-to-script/script in /etc/rc.local |
Quote:
This is what I am getting when I try to execute the script. ./firewall: line 28: syntax error: unexpected end of file 1 2 #!/bin/sh 3 4 ruleset_dir=/etc 5 case â<9c>$1â³ in 6 start) 7 echo -n â<9c>Loading iptables active ruleset: â<9d> 8 /sbin/iptables-restore < $ruleset_dir/iptables.rules 9 echo â<9c>done.â<9d> 10 ;; 11 stop) 12 echo -n â<9c>Loading iptables inactive ruleset: â<9d> 13 iptables -F INPUT 14 iptables -F OUTPUT 15 iptables -F FORWARD 16 iptables -P INPUT ACCEPT 17 iptables -P OUTPUT ACCEPT 18 iptables -P FORWARD DROP 19 echo â<9c>done.â<9d> 20 ;; 21 force-reload|restart) 22 $0 stop 23 sleep 1 24 $0 start 25 ;; 26 save) 27 echo -n â<9c>Saving iptables [...] Thanks again, Keith |
Quote:
Did you use the above script? Seems to me this is the firewall script. |
In your original post you had a script that began with the following lines:
# Written by Rober Penz <robert.penz@outertech.com> # This script is under GPL 2 or above Anyway I took that script and modified a couple of syntax errors in the INPUT section. The changes are noted below: Code:
$iptables -A INPUT -m state --state INVALID -m limit --limit 2/sec -j LOG --log-prefix "[#$rules_version : invalid input : ]" and Code:
$iptables -A INPUT -m state --state NEW,RELATED -p tcp --tcp-flags ! ALL SYN -j DROP Code:
#!/bin/bash Anyway after making those changes I booted Knoppix 5.3.1 which is as close as I can get to your environment. If I then execute 'iptables.sh' then we have the firewall rules that you had originally been working with which only allows ssh or port 22 inbound. Now the way Knoppix 5.3.1 deals with your firewall rules with respect to being able to have them survive a reboot is it expects the following files to be in /var/lib/iptables: active inactive because this directory and files do not exist you need to create them. Here is how I did it, first create the directory Code:
mkdir /var/lib/iptables Code:
/etc/init.d/iptables save active Note: The above command would need to run after the rules are in affect by having executed your script 'iptables.sh' Then to create the 'inactive' file you would run the following commands: Code:
/etc/init.d/iptables clear Code:
/etc/init.d/iptables save inactive Now if you issue the following commad: Code:
/etc/init.d/iptables stop Code:
iptables -L Code:
/etc/init.d/iptables start Code:
iptables -L Let me know if this worked Regards, Fordeck |
Quote:
Everything has worked I thank everyone again for their help!! Keith |
Quote:
Debian starts up in runlevel 2 - ALWAYS.. so adding a startup script in runlevel 3 would not do you much good. It would need to be added in rc2.d. Either way, Glad you got it all worked out. just wanted you to be aware of this discrepancy. |
Quote:
|
All times are GMT -5. The time now is 08:20 AM. |