IPCOP - How to block IP address's, ranges etc...

Here is my current rc.local file.

[code:1]
#!/bin/sh
#variables defined therein
. /var/ipcop/ethernet/settings

# Flush Custom Input Rules
/sbin/iptables -F CUSTOMINPUT
/sbin/iptables -F CUSTOMFORWARD


# shorthand helper
IPT="/sbin/iptables"

# echo-reply
$IPT -A CUSTOMINPUT -i $RED_DEV -p icmp --icmp-type 0 -j DROP
# echo-request
$IPT -A CUSTOMINPUT -i $RED_DEV -p icmp --icmp-type 8 -j DROP

# Now accept the three(3) good ones
# destination-unreachable
$IPT -A CUSTOMINPUT -i $RED_DEV -p icmp --icmp-type 3 -j ACCEPT
# redirect
$IPT -A CUSTOMINPUT -i $RED_DEV -p icmp --icmp-type 5 -j ACCEPT
# time exceeded
$IPT -A CUSTOMINPUT -i $RED_DEV -p icmp --icmp-type 11 -j ACCEPT

# Drop all other ICMP type data
$IPT -A CUSTOMINPUT -i $RED_DEV -p icmp -j DROP

# drop any tcp/udp packets to ports 135 - 137
$IPT -A CUSTOMINPUT -i $RED_DEV -p tcp --dport 135:137 -j DROP
$IPT -A CUSTOMINPUT -i $RED_DEV -p udp --dport 135:137 -j DROP


#restrict outgoing access

#allow full access for specific IPs
#PC1 - 192.168.111.1
#$IPT -A CUSTOMFORWARD -i $GREEN_DEV -s 192.168.111.1 -o $RED_DEV -j ACCEPT
#PC2 - 192.168.111.2
#$IPT -A CUSTOMFORWARD -i $GREEN_DEV -s 192.168.111.2 -o $RED_DEV -j ACCEPT

#allow limited access for specific IPs - in this case 192.168.111.3 tcp ports 20,21
#$IPT -A CUSTOMFORWARD -i $GREEN_DEV -s 192.168.111.3 -o $RED_DEV -p tcp --dport 21 -j ACCEPT
#$IPT -A CUSTOMFORWARD -i $GREEN_DEV -s 192.168.111.3 -o $RED_DEV -p tcp --dport 20 -j ACCEPT

#bar access for Internal IPs
$IPT -A CUSTOMFORWARD -i $GREEN_DEV -s 192.168.0.20 -o $RED_DEV -j DROP
#bar outside IP Access
$IPT -A CUSTOMFORWARD -i $RED_DEV -p tcp -m iprange --src-range 12.111.51.193-12.111.51.206 -j DROP[/code:1]
After running this and then even rebooting, it still dosen't appear to be doing anything. Here are the services that are running.

CRON server RUNNING
DHCP Server STOPPED
DNS proxy server RUNNING
Intrusion Detection System (GREEN) RUNNING
Intrusion Detection System (RED) RUNNING
Kernel logging server RUNNING
Logging server RUNNING
NTP Server STOPPED
Secure shell server RUNNING
VPN STOPPED
Web proxy STOPPED
Web server RUNNING

If I do get this to work, is just executing the rc.local file after making changes good enough to get things to work, or do I have to reboot after editing this file?

Also, after executing the rc.local file, is the /sbin/iptable file supposed to get updated or changed in anyway? The date never seems to change on it and it doesn't look like anything is getting added. I have run the rc.local file many times putting bogus commands in it at certain points to see if it was actually going all the way from start to finish, and it appears to run perfectly fine but I am not getting anything up on the Putty window but this.

root@ipcop:~ # . /etc/rc.d/rc.local
root@ipcop:~ #

No other indication that it ran.
I have looked at some of the IPCOP forums but there aren't many good ones in English that I can get more info from. There was one site that said to edit the rc.firewall.local file with your IPTABLES but no real good explaination on how to write a working IPTABLE. I trust this one should work since you seem to have it running on one of your boxes DaLight. Kinda stumped as to what to do now.

If I do get this to work, is just executing the rc.local file after making changes good enough to get things to work, or do I have to reboot after editing this file?

Also, after executing the rc.local file, is the /sbin/iptable file supposed to get updated or changed in anyway?

No, the /sbin/iptables (aliased to "IPT" within the script) is just the binary of the iptables application, which is just a command interface used to modify the ruleset stored in memory. The rc.local script is a shell script which is defined to run automatically on boot through some other shellscript. By running it, it is the same as if you literally type each one of it's lines through a terminal. It is normal that no output is returned.

Since the ruleset itself exists only in memory, it's lost after rebooting, that's why it needs to be created through a shellscript each time. In your rc.local script there are instructions to flush your chains, consequently there is no need for reboot: by executing rc.local the old rules will be flushed before the new rules are passed.

Just one thing, I noticed you put a dot in front of the full path (./etc/rc.d/rc.local), the "." is a hard link for your current path (according to your quotes, your home, /root ). So to execute the rc.local script you should either give the full path to it (/etc/rc.d/rc.local), or the relative path from where you are (../etc/rc.d/rc.local -the ".." is a hardlink for the parent directory).

nske's explanation is spot on regarding the role of the rc.local script. In addition, he spotted an error in your command line syntax which I missed. If you use the full path (/etc/rc.d/rc.local), I'm sure you will get the desired results.

I noticed you were looking for some indication that the command ran (apart fom observing the desired effects of course). The most reliable way is to run the following command:

[code:1]iptables -L[/code:1]

This will give a list of the active rules. You will then be able to spot any rules that you have added on. You can pipe the result to a text file and post it to the thread if you have any further problems.

In reply to your question on IPCOP IPTABLES support, I agree that there is not a lot of information around, however there is an abundance of information on IPTABLES itself. An excellent IPTABLES can be found tutorial at iptables-tutorial.frozentux.net/iptables-tutorial.html . This is how I learnt about IPTABLES.

The key things to note with regard to IPCOP is that the CUSTOMFORWARD, CUSTOMINPUT and CUSTOMOUTPUT chains are linked to the default FORWARD, INPUT and OUTPUT chains respectively. In addition, rules setup in the Port Forwarding and External Access GUI sections are stored in the PORTFWACCESS and XTACCESS chains respectively. XTACCESS is linked to the INPUT chain while PORTFWACCESS is linked to the FORWARD chain.

This is why it is best to make any changes to rc.local, and only to the CUSTOM* chains as these have been linked to the respective default chains in the rc.firewall file. There will also be less chance of conflicts between your custom rules and any rules setup via the GUI.

I believe I got it working thanks to your help and a little searching on the Smoothwall site. I neglected to mention I am running ADSL which I am sure you guys would have picked up on. Taking DaLights rc.local file and changing the "$RED_DEV" entrys to "ppp0" appears to have made it work. I got this info from this site:

martybugs.net/smoothwall/iptables.cgi

No where was there a nicely put script like DaLights so hats off to you and nske for your input. Here is the final code that I have to block all traffic from an internal IP out and all incoming traffic from an IP range coming in.

[code:1]
#!/bin/sh
#variables defined therein
. /var/ipcop/ethernet/settings

# Flush Custom Input Rules
/sbin/iptables -F CUSTOMINPUT
/sbin/iptables -F CUSTOMFORWARD


# shorthand helper
IPT="/sbin/iptables"

# echo-reply
$IPT -A CUSTOMINPUT -i ppp0 -p icmp --icmp-type 0 -j DROP
# echo-request
$IPT -A CUSTOMINPUT -i ppp0 -p icmp --icmp-type 8 -j DROP

# Now accept the three(3) good ones
# destination-unreachable
$IPT -A CUSTOMINPUT -i ppp0 -p icmp --icmp-type 3 -j ACCEPT
# redirect
$IPT -A CUSTOMINPUT -i ppp0 -p icmp --icmp-type 5 -j ACCEPT
# time exceeded
$IPT -A CUSTOMINPUT -i ppp0 -p icmp --icmp-type 11 -j ACCEPT

# Drop all other ICMP type data
$IPT -A CUSTOMINPUT -i ppp0 -p icmp -j DROP

# drop any tcp/udp packets to ports 135 - 137
$IPT -A CUSTOMINPUT -i ppp0 -p tcp --dport 135:137 -j DROP
$IPT -A CUSTOMINPUT -i ppp0 -p udp --dport 135:137 -j DROP


#restrict outgoing access

#allow full access for specific IPs
#PC1 - 192.168.111.1
#$IPT -A CUSTOMFORWARD -i $GREEN_DEV -s 192.168.111.1 -o ppp0 -j ACCEPT
#PC2 - 192.168.111.2
#$IPT -A CUSTOMFORWARD -i $GREEN_DEV -s 192.168.111.2 -o ppp0 -j ACCEPT

#allow limited access for specific IPs - in this case 192.168.111.3 tcp ports 20,21
#$IPT -A CUSTOMFORWARD -i $GREEN_DEV -s 192.168.111.3 -o ppp0 -p tcp --dport 21 -j ACCEPT
#$IPT -A CUSTOMFORWARD -i $GREEN_DEV -s 192.168.111.3 -o ppp0 -p tcp --dport 20 -j ACCEPT

#bar access for Internal IPs
#$IPT -A CUSTOMFORWARD -i $GREEN_DEV -s 192.168.0.20 -o ppp0 -j DROP
#bar outside IP Access
#$IPT -A CUSTOMFORWARD -i ppp0 -p tcp -m iprange --src-range 12.111.51.193-12.111.51.206 -j DROP#!/bin/sh
#variables defined therein
. /var/ipcop/ethernet/settings

# Flush Custom Input Rules
/sbin/iptables -F CUSTOMINPUT
/sbin/iptables -F CUSTOMFORWARD


# shorthand helper
IPT="/sbin/iptables"

# echo-reply
$IPT -A CUSTOMINPUT -i ppp0 -p icmp --icmp-type 0 -j DROP
# echo-request
$IPT -A CUSTOMINPUT -i ppp0 -p icmp --icmp-type 8 -j DROP

# Now accept the three(3) good ones
# destination-unreachable
$IPT -A CUSTOMINPUT -i ppp0 -p icmp --icmp-type 3 -j ACCEPT
# redirect
$IPT -A CUSTOMINPUT -i ppp0 -p icmp --icmp-type 5 -j ACCEPT
# time exceeded
$IPT -A CUSTOMINPUT -i ppp0 -p icmp --icmp-type 11 -j ACCEPT

# Drop all other ICMP type data
$IPT -A CUSTOMINPUT -i ppp0 -p icmp -j DROP

# drop any tcp/udp packets to ports 135 - 137
$IPT -A CUSTOMINPUT -i ppp0 -p tcp --dport 135:137 -j DROP
$IPT -A CUSTOMINPUT -i ppp0 -p udp --dport 135:137 -j DROP


#restrict outgoing access

#allow full access for specific IPs
#PC1 - 192.168.111.1
#$IPT -A CUSTOMFORWARD -i $GREEN_DEV -s 192.168.111.1 -o ppp0 -j ACCEPT
#PC2 - 192.168.111.2
#$IPT -A CUSTOMFORWARD -i $GREEN_DEV -s 192.168.111.2 -o ppp0 -j ACCEPT

#allow limited access for specific IPs - in this case 192.168.111.3 tcp ports 20,21
#$IPT -A CUSTOMFORWARD -i $GREEN_DEV -s 192.168.111.3 -o ppp0 -p tcp --dport 21 -j ACCEPT
#$IPT -A CUSTOMFORWARD -i $GREEN_DEV -s 192.168.111.3 -o ppp0 -p tcp --dport 20 -j ACCEPT

#bar access for Internal IPs
$IPT -A CUSTOMFORWARD -i $GREEN_DEV -s 192.168.0.20 -o ppp0 -j DROP
#bar outside IP Access
$IPT -A CUSTOMFORWARD -i ppp0 -p tcp -m iprange --src-range 12.111.51.193-12.111.51.206 -j DROP[/code:1]

I have nullified and left some of the entry's that you have in the script just incase I want to do something further with this in the future.
I just have one more question on blocking of IP Ranges. How would I block the range 12.111.51.193-12.111.51.206 using this IP notation:

12.111.51.192/28

Would it be..

$IPT -A CUSTOMFORWARD -i ppp0 -p tcp -m iprange --src-range 12.111.51.192/28 -j DROP

That way, if I want to just take out an entire subnet in a nice neat shorter command I just have to do a whois on the IP and get the info from there. This makes running a game server a lot easier when you get the "Dynamic IP Idiot" that keeps connecting using different names and from different IP's on the same subnet.

P.S

/etc/rc.d/rc.local works just nice. I have to run a script everyday multiple times that has a "." in it, and being a Micro$oft Admin, I have been trained like a monkey to run this on an AIX machine without knowing what the hell I am typing. I haven't really had to dive into Linux or Unix much at all where I work, but at home, I am trying to learn it on my own. You should have seen it when I was finally able to setup a network printer on my Linux test machine. It was a mini movie comparable to Die Hard.

Glad to hear that everything's sorted out MudVayne. I've also learnt something new. I wasn't aware that you could not use the $RED_DEV alias in certain situations as stated in the link you found:

Note that if your red interface is a modem, ISDN, or using PPPoE or PPPoA, you can't use the $RED_DEV alias, but need to specify the actual interface name, for example, ppp0.

It's quite a good link as most of the stuff can also be applied to IPCOP.

As for your question on blocking IP ranges using netmask notation, it is actually easier as we can use the same syntax as for single ports. The command would be:

[code:1]
$IPT -A CUSTOMFORWARD -i ppp0 -s 12.111.51.192/28 -j DROP
[/code:1]

You will note that I dropped the "-p tcp" option. You can drop it for the other form of the command as well. This option specifies that we want to drop only tcp connections, but since we want to block all access, omitting it will block all protocols.

Again, thank you very much for all of your input. I will try to take it from here so I can actually learn some of this. I think I have a pretty good head start.

P.S.
Wish I could buy you a pint glass for everything you've done. Wouldn't have gotten anywhere without the help of this board.
Oh yeah, on a side note. If you ever cross paths with Ricky "The Hitman" Hatten over there in Manchester. Tell him hes got two huge fans in my wife and me that want to see him kick Floyd Mayweather Jr's arsh.