Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I'm using IPCop to segment three LAN's in a repair shop. We use the green interface for the internal LAN (workstations and servers), the blue interface for providing internet access to "dirty" systems, and the orange interface for a "somewhat dirty" LAN, used for downloading updates, etc. for all the rest of the general repairs we are working on. Red interface is obviously a high speed internet connection.
All works wonderfully, however I am concerned that the blue network has the ability to contact the orange network. Granted, this would not likely happen since any potentially infected machine on the blue interface would not be aware of the route allowing access to the orange subnet, but I would still like to close this hole. Basically, I would like the blue interface to behave, routing-wise, just like the orange. No access to anywhere except out to the internet.
I have edited the file allowing blue access by IP address, entering all IP's in the subnet. However, this by definition allows access to both the red and orange interfaces. I would like to change this behavior to allow blue access ONLY to the red interface, and block access into orange.
Does anyone know how to adjust/modify what i would term the "zone cross-talk" rules?
Any help would be fantastic. Thanks very much in advance.
Here is the administrative guide to IPCop. The firewall rules describing the default access between the interfaces is here. By default, computers on the blue interface cannot connect to any of the other interfaces. (You can verify this by trying to ping, by IP address -- not name -- from a computer on the blue interface to a computer on any other interface. Disable the firewalls on the two machines for this test, or at least makes sure they allow pings in both directions, so you know the blocking is from IPCop and not a host firewall.) The way to enable access from blue to elsewhere is described here.
Thanks for the reply. I've been all over the manuals, and also been using the system for several years, since version 1.30. I'm well versed in the system, as far as normal configurations go.
Since I'm using the blue interface for essentially a second LAN, I have had to grant every IP address on that subnet access through the "blue access" page. Works great, all systems on blue can access the internet, as advertised.
The behavior I'd like to change is that once given access via the "blue access", the access granted is both blue->red and blue->orange. I'm trying to eliminate the blue->orange route, such that blue interface behaves similarly to orange, whose only route is orange->red, nowhere else.
I realize this is an outside-the-envelope adjustment, and the dev's have not documented a way to do this, because, well, why would anyone want to?
I'd be more than happy to post the contents of any/all network configuration files, so that someone versed in setting up routes could analyze them, see the routes that are already in place, and possibly help me figure this out.
The manual does offer a config file for users to add custom changes, but I'm not well versed enough in linux configurations to create the rule myself.
Again, thanks very much for the reply. I hope I've explained the issue clearly enough.
The behavior I'd like to change is that once given access via the "blue access", the access granted is both blue->red and blue->orange.
I didn't realize that. I thought the graphical interface gave you finer control than that. I played with IPCop for about half a day just to see what it was and to evaluate it (I was fairly impressed!), but I didn't really have a use for it.
Quote:
I'm trying to eliminate the blue->orange route, such that blue interface behaves similarly to orange, whose only route is orange->red, nowhere else.
[ ...]
I'd be more than happy to post the contents of any/all network configuration files, so that someone versed in setting up routes could analyze them, see the routes that are already in place, and possibly help me figure this out.
The manual does offer a config file for users to add custom changes, but I'm not well versed enough in linux configurations to create the rule myself.
Rather than trying to do this with routing, I think it makes a lot more sense to add a simple rule to your firewall using an iptables command. I've just glanced over the documentation on the IPCop site, and I saw mention of using rc.local for customization. I thought I remembered another file that was specifically designed for adding custom firewall rules. Or maybe it was just specific user chains (in netfiler/iptables) to put the custom rules in. If you can clue me in about the config files and post your existing firewall rules and tell me which interface (eth0, etc) you use for RED and BLUE, I can tell you specifically where to add the rule. But in general, one rule that would work would look something like:
Code:
# netefilter rule to prevent the BLUE interface from accessing any interface other than RED
# Define $BLUE_INT and $RED_INT to their respective devices, e.g. eth0.
# Set $CHAIN to FORWARD or an appropriate user chain called from the FORWARD chain.
# DROP may be changed to REJECT if you prefer to have an ICMP sent back when a packet is blocked.
BLUE_INT=
RED_INT=
CHAIN=
/sbin/iptables -A $CHAIN -i $BLUE_INT -o ! $RED_INT -j DROP
When you make the change, please do verify that it has the behavior you want by trying to access ORANGE from BLUE.
Also, note that this rule does not prevent BLUE from accessing the IPCop box itself. I think you have enough control over that from your graphical interface, but if you need additional rules for that, let me know your requirements.
EDIT: You may output all of the firewall rules (in the netfilter chain, which is the only concern here) with the command, as root:
Code:
iptables -nvL
EDIT2: If you are giving "dirty" boxes Internet access (high speed at that!), I certainly hope you are being a good netizen and being very restrictive about what these boxes can do with their access! Perhaps some more custom firewall rules are in order? I am no security expert, but I am not sure it is even safe to let them access port 80. (ALthough, IIRC, IPCop does already check packets for various weird combinations of tcp-flags, which might mitigate attacks on port 80.)
Last edited by blackhole54; 10-04-2007 at 01:32 AM.
Fantastic. Your approach sounds more logical to me.
btw, what I refer to as "dirty" systems are simply machines that are post-repair, but not part of out in-house network. We like to keep things as locked down as possible, for security purposes. I'd never allow one of my techs to connect an infested system to the 'net! That said, I'd also be interested in what I can do with a few more firewall rules to tweak the access a bit more. Sounds good.
Here's the output of "iptables -nvL"
-> begin output:
Chain WIRELESSFORWARD (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- eth1 !eth0 192.168.5.2 0.0.0.0/0
0 0 DMZHOLES all -- eth1 * 192.168.5.2
SNIP---------
(would only let me post 25000 characters)
SNIP---------
192.168.5.254 0.0.0.0/0
0 0 DMZHOLES all -- eth1 * 192.168.5.254 0.0.0.0/0
29 2088 LOG_DROP all -- eth1 * 0.0.0.0/0 0.0.0.0/0
Chain WIRELESSINPUT (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- eth1 * 192.168.5.2 0.0.0.0/0
0 0 ACCEPT all -- eth1 * 192.168.5.3 0.0.0.0/0
0 0 ACCEPT all -- eth1 * 192.168.5.4 0.0.0.0/0
0 0 ACCEPT all -- eth1 * 192.168.5.5
SNIP---------
SNIP---------
0 0 ACCEPT all -- eth1 * 192.168.5.249 0.0.0.0/0
0 0 ACCEPT all -- eth1 * 192.168.5.250 0.0.0.0/0
0 0 ACCEPT all -- eth1 * 192.168.5.251 0.0.0.0/0
0 0 ACCEPT all -- eth1 * 192.168.5.252 0.0.0.0/0
0 0 ACCEPT all -- eth1 * 192.168.5.253 0.0.0.0/0
0 0 ACCEPT all -- eth1 * 192.168.5.254 0.0.0.0/0
0 0 LOG_DROP all -- eth1 * 0.0.0.0/0 0.0.0.0/0
Chain XTACCESS (1 references)
pkts bytes target prot opt in out source destination
Chain ipac~fi (1 references)
pkts bytes target prot opt in out source destination
125 8293 all -- eth0 * 0.0.0.0/0 0.0.0.0/0
32 1886 all -- eth3 * 0.0.0.0/0 0.0.0.0/0
0 0 all -- eth1 * 0.0.0.0/0 0.0.0.0/0
116 16038 all -- eth2 * 0.0.0.0/0 0.0.0.0/0
Chain ipac~fo (1 references)
pkts bytes target prot opt in out source destination
83 13377 all -- * eth0 0.0.0.0/0 0.0.0.0/0
33 2661 all -- * eth3 0.0.0.0/0 0.0.0.0/0
0 0 all -- * eth1 0.0.0.0/0 0.0.0.0/0
157 10179 all -- * eth2 0.0.0.0/0 0.0.0.0/0
Chain ipac~i (1 references)
pkts bytes target prot opt in out source destination
0 0 all -- * eth0 0.0.0.0/0 0.0.0.0/0
0 0 all -- * eth3 0.0.0.0/0 0.0.0.0/0
0 0 all -- * eth1 0.0.0.0/0 0.0.0.0/0
120 12517 all -- * eth2 0.0.0.0/0 0.0.0.0/0
Chain ipac~o (1 references)
pkts bytes target prot opt in out source destination
2 458 all -- eth0 * 0.0.0.0/0 0.0.0.0/0
15 1542 all -- eth3 * 0.0.0.0/0 0.0.0.0/0
0 0 all -- eth1 * 0.0.0.0/0 0.0.0.0/0
144 15172 all -- eth2 * 0.0.0.0/0 0.0.0.0/0
-> end output
Sorry for the verbosity, but I didn't want to leave anything out.
-The 192.168.0.0 network is the 'green' protected lan
-The 192.168.1.0 network is the 'orange', dmz, second lan for the repaired public systems
-The 192.168.5.0 network is the 'blue', which I am trying to block from accessing orange.
eth0=green
eth1=blue
eth2=red (isp)
eth3=orange
Administrative access to the box itself is hardened a bit by using non-standard ports and security certificates, as well as user/pwd authentication.
Again, thanks a million for taking the time to help me out.
I'd never allow one of my techs to connect an infested system to the 'net! That said, I'd also be interested in what I can do with a few more firewall rules to tweak the access a bit more.
Whew!!! I had one of those OMG moments when my mind was wandering and I suddenly realized you were talking about "dirty" boxes and the Internet. Thanks for the clarification.
It looks like your custom forwarding rules are intended to go in the CUSTOMFORWARD chain. I am a bit surprised to see a couple rules there already, but no matter. I am assuming the rules you have just posted are already in place by the time rc.local gets executed, which is where we will place instructions for new rules. To demonstrate how to use additional rules to limit Internet access for the BLUE interface (per your request above), I will set this up to severely restrict what the BLUE network can do on the Internet by creating the user chain BLUE_INET_ALLOW. If you don't want to do this, just eliminate all statements with BLUE_INET_ALLOW in them.
So add the following to your /etc/rc.d/rc.local file. Every statement that starts with a hash mark (#) is a comment, which you can modify or eliminate as you see fit.
Code:
# Some convenient definitions:
BLUE_INT=eth1
RED_INT=eth2
IPT=/sbin/iptables
# Create a new user chain which will contain explicit rules of what the
# BLUE interface can access on the Internet. This follows a "deny everything
# that is not allowed" philosophy. Packets that are allowed are RETURNed
# for further checking. All other packets are unceremoniously dropped!
# (If you wish to log these packets, you can add a -j LOG rule prior to
# DROPping, or you can use -j LOG_DROP instead of -j DROP.)
# For now, allow only tcp/80 (http) and tcp/443 (https). I believe DNS
# requests are made directly to IPCop, so we don't need to allow DNS to
# the Internet.
# Note that these rules *do not* affect access to the IPCop box itself.
$IPT -N BLUE_INET_ALLOW
$IPT -A BLUE_INET_ALLOW -p tcp --dport 80 -j RETURN
$IPT -A BLUE_INET_ALLOW -p tcp --dport 443 -j RETURN
$IPT -A BLUE_INET_ALLOW -j DROP
# Restrict the BLUE interface from accessing any interface other than RED
# and send all other BLUE interface packets to BLUE_INET_ALLOW for additional
# restrictions.
$IPT -A CUSTOMFORWARD -i $BLUE_INT -o ! $RED_INT -j DROP
$IPT -A CUSTOMFORWARD -i $BLUE_INT -j BLUE_INET_ALLOW
If neither of us has made any mistakes, these rules should be in place when you reboot IPCop. I suggest you check by listing the chains you just created/altered by (as root):
pkts bytes target prot opt in out source destination
5640K 4547M OVPNFORWARD all -- * * 0.0.0.0/0 0.0.0.0/0
5620K 4546M OVPN_BLUE_FORWARD all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 DROP all -- eth1 !eth2 0.0.0.0/0 0.0.0.0/0
0 0 BLUE_INET_ALLOW all -- eth1 * 0.0.0.0/0 0.0.0.0/0
(Dont worry about the numbers in the first two columns -- they reflect the packets that have already matched the rule.)
I also suggest verifying that the BLUE is actually being blocked by trying to ping something on the ORANGE interface from something on the BLUE interface. Not only should it fail, but you should see a corresponding packet and byte count registered in the first two columns of the DROP rule above.
I hope I have answered, by example, your question about additional firewall rules. Let me know if you have more questions.
Quote:
Sorry for the verbosity, but I didn't want to leave anything out.
That's what I asked for. BTW, you used some judicious snipping! I didn't realize it was going to enumerate every address like that! I also was unaware of the 25000 byte limit, but I guess you have to have some limit. For future reference, when you post computer output, it will be easier to read if you rap "code tags" around it. (That will cause everything to line up the way it was originally, and prevent weird "smilies" from showing up in the middle of it.) You can do this by highlighting the text and pressing the hash mark (#) above your edit box. Or you can do what I usually do and just type them in manually. (Use the hash mark in the toolbar to find out what they are if you don't know.)
Last edited by blackhole54; 10-05-2007 at 02:41 AM.
Reason: typo
I truly appreciate all the help.
That code looks great, but...
I copied the text verbatim into the rc.local file. Rebooted the box. No effect.
iptables -nvL CUSTOMFORWARD
shows the same rules as before the edit
iptables -nvL BLUE_INET_ALLOW
produces:
"iptables: No chain/target/match by that name"
Any more ideas? I re-read that section of the admin manual, and it seems to suggest that we use the "rc.firewall.local" file for firewall modifications. Would the syntax be the same within that file? Here are its contents:
Code:
#!/bin/sh
# Used for private firewall rules
# See how we were called.
case "$1" in
start)
## add your 'start' rules here
#Added for zerina start - BEGIN
/usr/local/bin/openvpnctrl --create-chains-and-rules
#Added for zerina start - END
;;
stop)
## add your 'stop' rules here
#Added for zerina stop - BEGIN
/usr/local/bin/openvpnctrl --delete-chains-and-rules
#Added for zerina stop - END
;;
reload)
$0 stop
$0 start
## add your 'reload' rules here
;;
*)
echo "Usage: $0 {start|stop|reload}"
;;
esac
And here is rc.firewall:
Code:
#!/bin/sh
#
# $Id: rc.firewall,v 1.7.2.22 2007/03/22 21:10:11 franck78 Exp $
#
eval $(/usr/local/bin/readhash /var/ipcop/ppp/settings)
eval $(/usr/local/bin/readhash /var/ipcop/ethernet/settings)
IFACE=`/bin/cat /var/ipcop/red/iface 2> /dev/null | /usr/bin/tr -d '\012'`
if [ -f /var/ipcop/red/device ]; then
DEVICE=`/bin/cat /var/ipcop/red/device 2> /dev/null | /usr/bin/tr -d '\012'`
fi
iptables_init() {
# Flush all rules and delete all custom chains
/sbin/iptables -F
/sbin/iptables -t nat -F
/sbin/iptables -t mangle -F
/sbin/iptables -X
/sbin/iptables -t nat -X
/sbin/iptables -t mangle -X
# Set up policies
/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT ACCEPT
# Empty LOG_DROP and LOG_REJECT chains
/sbin/iptables -N LOG_DROP
/sbin/iptables -A LOG_DROP -m limit --limit 10/minute -j LOG
/sbin/iptables -A LOG_DROP -j DROP
/sbin/iptables -N LOG_REJECT
/sbin/iptables -A LOG_REJECT -m limit --limit 10/minute -j LOG
/sbin/iptables -A LOG_REJECT -j REJECT
# This chain will log, then DROPs packets with certain bad combinations
# of flags might indicate a port-scan attempt (xmas, null, etc)
/sbin/iptables -N PSCAN
/sbin/iptables -A PSCAN -p tcp -m limit --limit 10/minute -j LOG --log-prefix "TCP Scan? "
/sbin/iptables -A PSCAN -p udp -m limit --limit 10/minute -j LOG --log-prefix "UDP Scan? "
/sbin/iptables -A PSCAN -p icmp -m limit --limit 10/minute -j LOG --log-prefix "ICMP Scan? "
/sbin/iptables -A PSCAN -f -m limit --limit 10/minute -j LOG --log-prefix "FRAG Scan? "
/sbin/iptables -A PSCAN -j DROP
# New tcp packets without SYN set - could well be an obscure type of port scan
# that's not covered above, may just be a broken windows machine
/sbin/iptables -N NEWNOTSYN
/sbin/iptables -A NEWNOTSYN -m limit --limit 10/minute -j LOG --log-prefix "NEW not SYN? "
/sbin/iptables -A NEWNOTSYN -j DROP
# Chain to contain all the rules relating to bad TCP flags
/sbin/iptables -N BADTCP
# Disallow packets frequently used by port-scanners
# nmap xmas
/sbin/iptables -A BADTCP -p tcp --tcp-flags ALL FIN,URG,PSH -j PSCAN
# Null
/sbin/iptables -A BADTCP -p tcp --tcp-flags ALL NONE -j PSCAN
# FIN
/sbin/iptables -A BADTCP -p tcp --tcp-flags ALL FIN -j PSCAN
# SYN/RST (also catches xmas variants that set SYN+RST+...)
/sbin/iptables -A BADTCP -p tcp --tcp-flags SYN,RST SYN,RST -j PSCAN
# SYN/FIN (QueSO or nmap OS probe)
/sbin/iptables -A BADTCP -p tcp --tcp-flags SYN,FIN SYN,FIN -j PSCAN
# NEW TCP without SYN
/sbin/iptables -A BADTCP -p tcp ! --syn -m state --state NEW -j NEWNOTSYN
/sbin/iptables -A INPUT -j BADTCP
/sbin/iptables -A FORWARD -j BADTCP
}
iptables_red() {
/sbin/iptables -F REDINPUT
/sbin/iptables -F REDFORWARD
/sbin/iptables -t nat -F REDNAT
# PPPoE / PPTP Device
if [ "$IFACE" != "" ]; then
# PPPoE / PPTP
if [ "$DEVICE" != "" ]; then
/sbin/iptables -A REDINPUT -i $DEVICE -j ACCEPT
fi
if [ "$RED_TYPE" == "PPTP" -o "$RED_TYPE" == "PPPOE" ]; then
if [ "$RED_DEV" != "" ]; then
/sbin/iptables -A REDINPUT -i $RED_DEV -j ACCEPT
fi
fi
fi
# PPTP over DHCP
if [ "$DEVICE" != "" -a "$TYPE" == "PPTP" -a "$METHOD" == "DHCP" ]; then
/sbin/iptables -A REDINPUT -p tcp --source-port 67 --destination-port 68 -i $DEVICE -j ACCEPT
/sbin/iptables -A REDINPUT -p udp --source-port 67 --destination-port 68 -i $DEVICE -j ACCEPT
fi
# Orange pinholes
if [ "$ORANGE_DEV" != "" ]; then
# This rule enables a host on ORANGE network to connect to the outside
# (only if we have a red connection)
if [ "$IFACE" != "" ]; then
/sbin/iptables -A REDFORWARD -i $ORANGE_DEV -p tcp -o $IFACE -j ACCEPT
/sbin/iptables -A REDFORWARD -i $ORANGE_DEV -p udp -o $IFACE -j ACCEPT
fi
fi
if [ "$IFACE" != "" -a -f /var/ipcop/red/active ]; then
# DHCP
if [ "$RED_DEV" != "" -a "$RED_TYPE" == "DHCP" ]; then
/sbin/iptables -A REDINPUT -p tcp --source-port 67 --destination-port 68 -i $IFACE -j ACCEPT
/sbin/iptables -A REDINPUT -p udp --source-port 67 --destination-port 68 -i $IFACE -j ACCEPT
fi
if [ "$METHOD" == "DHCP" -a "$PROTOCOL" == "RFC1483" ]; then
/sbin/iptables -A REDINPUT -p tcp --source-port 67 --destination-port 68 -i $IFACE -j ACCEPT
/sbin/iptables -A REDINPUT -p udp --source-port 67 --destination-port 68 -i $IFACE -j ACCEPT
fi
# Outgoing masquerading
/sbin/iptables -t nat -A REDNAT -o $IFACE -j MASQUERADE
fi
}
# See how we were called.
case "$1" in
start)
iptables_init
# Limit Packets- helps reduce dos/syn attacks
# original do nothing line
#/sbin/iptables -A INPUT -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -m limit --limit 10/sec
# the correct one, but the negative '!' do nothing...
#/sbin/iptables -A INPUT -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -m limit ! --limit 10/sec -j DROP
# Fix for braindead ISP's
/sbin/iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
# CUSTOM chains, can be used by the users themselves
/sbin/iptables -N CUSTOMINPUT
/sbin/iptables -A INPUT -j CUSTOMINPUT
/sbin/iptables -N CUSTOMFORWARD
/sbin/iptables -A FORWARD -j CUSTOMFORWARD
/sbin/iptables -N CUSTOMOUTPUT
/sbin/iptables -A OUTPUT -j CUSTOMOUTPUT
/sbin/iptables -t nat -N CUSTOMPREROUTING
/sbin/iptables -t nat -A PREROUTING -j CUSTOMPREROUTING
/sbin/iptables -t nat -N CUSTOMPOSTROUTING
/sbin/iptables -t nat -A POSTROUTING -j CUSTOMPOSTROUTING
# filtering from GUI
/sbin/iptables -N GUIINPUT
/sbin/iptables -A INPUT -j GUIINPUT
# Accept everything connected
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# trafic from ipsecX/TUN/TAP interfaces, before "-i GREEN_DEV" accept everything
/sbin/iptables -N IPSECVIRTUAL
/sbin/iptables -N OPENSSLVIRTUAL
/sbin/iptables -A INPUT -j IPSECVIRTUAL
/sbin/iptables -A INPUT -j OPENSSLVIRTUAL
/sbin/iptables -A FORWARD -j IPSECVIRTUAL
/sbin/iptables -A FORWARD -j OPENSSLVIRTUAL
# localhost and ethernet.
/sbin/iptables -A INPUT -i lo -m state --state NEW -j ACCEPT
/sbin/iptables -A INPUT -s 127.0.0.0/8 -m state --state NEW -j DROP # Loopback not on lo
/sbin/iptables -A INPUT -d 127.0.0.0/8 -m state --state NEW -j DROP
/sbin/iptables -A FORWARD -i lo -m state --state NEW -j ACCEPT
/sbin/iptables -A FORWARD -s 127.0.0.0/8 -m state --state NEW -j DROP
/sbin/iptables -A FORWARD -d 127.0.0.0/8 -m state --state NEW -j DROP
/sbin/iptables -A INPUT -i $GREEN_DEV -m state --state NEW -j ACCEPT -p ! icmp
/sbin/iptables -A FORWARD -i $GREEN_DEV -m state --state NEW -j ACCEPT
# If a host on orange tries to initiate a connection to IPCop's red IP and
# the connection gets DNATed back through a port forward to a server on orange
# we end up with orange -> orange traffic passing through IPCop
[ "$ORANGE_DEV" != "" ] && /sbin/iptables -A FORWARD -i $ORANGE_DEV -o $ORANGE_DEV -m state --state NEW -j ACCEPT
# allow DHCP on BLUE to be turned on/off
/sbin/iptables -N DHCPBLUEINPUT
/sbin/iptables -A INPUT -j DHCPBLUEINPUT
# IPSec
/sbin/iptables -N IPSECPHYSICAL
/sbin/iptables -A INPUT -j IPSECPHYSICAL
# OPenSSL
/sbin/iptables -N OPENSSLPHYSICAL
/sbin/iptables -A INPUT -j OPENSSLPHYSICAL
# WIRELESS chains
/sbin/iptables -N WIRELESSINPUT
/sbin/iptables -A INPUT -m state --state NEW -j WIRELESSINPUT
/sbin/iptables -N WIRELESSFORWARD
/sbin/iptables -A FORWARD -m state --state NEW -j WIRELESSFORWARD
# RED chain, used for the red interface
/sbin/iptables -N REDINPUT
/sbin/iptables -A INPUT -j REDINPUT
/sbin/iptables -N REDFORWARD
/sbin/iptables -A FORWARD -j REDFORWARD
/sbin/iptables -t nat -N REDNAT
/sbin/iptables -t nat -A POSTROUTING -j REDNAT
iptables_red
# DMZ pinhole chain. setdmzholes setuid prog adds rules here to allow
# ORANGE to talk to GREEN / BLUE.
/sbin/iptables -N DMZHOLES
if [ "$ORANGE_DEV" != "" ]; then
/sbin/iptables -A FORWARD -i $ORANGE_DEV -m state --state NEW -j DMZHOLES
fi
# XTACCESS chain, used for external access
/sbin/iptables -N XTACCESS
/sbin/iptables -A INPUT -m state --state NEW -j XTACCESS
# PORTFWACCESS chain, used for portforwarding
/sbin/iptables -N PORTFWACCESS
/sbin/iptables -A FORWARD -m state --state NEW -j PORTFWACCESS
# Custom prerouting chains (for transparent proxy and port forwarding)
/sbin/iptables -t nat -N SQUID
/sbin/iptables -t nat -A PREROUTING -j SQUID
/sbin/iptables -t nat -N PORTFW
/sbin/iptables -t nat -A PREROUTING -j PORTFW
# Custom mangle chain (for port fowarding)
/sbin/iptables -t mangle -N PORTFWMANGLE
/sbin/iptables -t mangle -A PREROUTING -j PORTFWMANGLE
# Postrouting rules (for port forwarding)
/sbin/iptables -t nat -A POSTROUTING -m mark --mark 1 -j SNAT \
--to-source $GREEN_ADDRESS
if [ "$BLUE_DEV" != "" ]; then
/sbin/iptables -t nat -A POSTROUTING -m mark --mark 2 -j SNAT --to-source $BLUE_ADDRESS
fi
if [ "$ORANGE_DEV" != "" ]; then
/sbin/iptables -t nat -A POSTROUTING -m mark --mark 3 -j SNAT --to-source $ORANGE_ADDRESS
fi
# run local firewall configuration, if present
if [ -x /etc/rc.d/rc.firewall.local ]; then
/etc/rc.d/rc.firewall.local start
fi
# last rule in input and forward chain is for logging.
/sbin/iptables -A INPUT -m limit --limit 10/minute -j LOG --log-prefix "INPUT "
/sbin/iptables -A FORWARD -m limit --limit 10/minute -j LOG --log-prefix "OUTPUT "
;;
stop)
iptables_init
# Accept everyting connected
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# localhost and ethernet.
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A INPUT -i $GREEN_DEV -m state --state NEW -j ACCEPT
if [ "$RED_DEV" != "" -a "$RED_TYPE" == "DHCP" ]; then
/sbin/iptables -A INPUT -p tcp --source-port 67 --destination-port 68 -i $IFACE -j ACCEPT
/sbin/iptables -A INPUT -p udp --source-port 67 --destination-port 68 -i $IFACE -j ACCEPT
fi
if [ "$PROTOCOL" == "RFC1483" -a "$METHOD" == "DHCP" ]; then
/sbin/iptables -A INPUT -p tcp --source-port 67 --destination-port 68 -i $IFACE -j ACCEPT
/sbin/iptables -A INPUT -p udp --source-port 67 --destination-port 68 -i $IFACE -j ACCEPT
fi
# run local firewall configuration, if present
if [ -x /etc/rc.d/rc.firewall.local ]; then
/etc/rc.d/rc.firewall.local stop
fi
/sbin/iptables -A INPUT -m limit --limit 10/minute -j LOG --log-prefix "INPUT "
/sbin/iptables -A FORWARD -m limit --limit 10/minute -j LOG --log-prefix "OUTPUT "
;;
reload)
iptables_red
# run local firewall configuration, if present
if [ -x /etc/rc.d/rc.firewall.local ]; then
/etc/rc.d/rc.firewall.local reload
fi
;;
restart)
$0 stop
$0 start
;;
*)
echo "Usage: $0 {start|stop|reload|restart}"
exit 1
;;
esac
exit 0
Edit:
Coincidentally, now that I've gotten home from the office I can see that those rules appear to have broken OpenVPN (aka "Zerina" add-on), I can't connect at all. Perhaps we have the interfaces mixed up?
Last edited by jmcskixc; 10-05-2007 at 06:53 PM.
Reason: more info:
I think rc.firewall.local is the file I was trying to think of in post #4, but I didn't see any mention of it when I was looking at the FAQ. So that would be the logical place to put these new rules. (And as an aside, the code that is already in that file is presumably the source of the rules already in the CUSTOM* chains that I was musing about.). Thing is (jumping around in your post a little), if the rules didn't take, then they couldn't have busted anything. If you haven't already done so, the first thing I would suggest is to see if you can go back to where you were with no new rules and see if you can get your VPN back.
Once you have things back the way they were, you can double check which interface is which using the /sbin/ifconfig command w/o parameters. Pipe the results into less, and on each interface (eth0 - eth3) you can see the address for that interface, and confirm which is RED, which is BLUE, etc. After everything is working as before and you are satisfied you know which interface is which, add the rules to rc.firewall.local as below. I've omitted the comments this time; of course, you can add comments as you desire.
Code:
#!/bin/sh
# Used for private firewall rules
BLUE_INT=eth1
RED_INT=eth2
IPT=/sbin/iptables
# See how we were called.
case "$1" in
start)
## add your 'start' rules here
#Added for zerina start - BEGIN
/usr/local/bin/openvpnctrl --create-chains-and-rules
#Added for zerina start - END
$IPT -N BLUE_INET_ALLOW
$IPT -A BLUE_INET_ALLOW -p tcp --dport 80 -j RETURN
$IPT -A BLUE_INET_ALLOW -p tcp --dport 443 -j RETURN
$IPT -A BLUE_INET_ALLOW -j DROP
$IPT -A CUSTOMFORWARD -i $BLUE_INT -o ! $RED_INT -j DROP
$IPT -A CUSTOMFORWARD -i $BLUE_INT -j BLUE_INET_ALLOW
;;
stop)
## add your 'stop' rules here
#Added for zerina stop - BEGIN
/usr/local/bin/openvpnctrl --delete-chains-and-rules
#Added for zerina stop - END
;;
reload)
$0 stop
$0 start
## add your 'reload' rules here
;;
*)
echo "Usage: $0 {start|stop|reload}"
;;
esac
I have no experience with VPN or IPSec, but I am pretty sure the rules added should not interfere if the interfaces are correct. The rules should only affect packets that are entering on the BLUE interface. I suppose it is possible that since I told you to put the rules in the wrong file that there was some kind of weird side effect that screwed things up ...
Hopefully with the rules as shown above, when you check
you will see the expected results this time. If you run into trouble with VPN again and wish to troubleshoot, you can comment out either or both of the rules added to the CUSTOMFORWARD chain by adding a hash mark at the beginning of the line. Commenting out the last rule (-j BLUE_INET_ALLOW) is sufficient for making the BLUE_INET_ALLOW chain irrelevant -- you don't need to actually comment out the chain itself.
I think the way I have shown rc.firewall.local is what you want when a stop parameter is provided. With stop, rc.firewall first deletes all existing rules and then adds some back. With nothing added to the stop branch of rc.firewall.local, the new rules you are adding for the BLUE interface will not be included. Does that make sense to you?
EDIT: I neglected to specifically answer your question:
Quote:
Would the syntax be the same within that file?
The answer is yes.
Last edited by blackhole54; 10-06-2007 at 01:12 AM.
OK, set the rc.local file back to stock and copied the new text into the rc.firewall.local. Rebooted the box.
Code:
login as: root
root@192.168.0.1's password:
Last login: Sat Oct 6 12:09:20 2007 from 192.168.0.102
root@ipcop:~ # iptables -nvL CUSTOMFORWARD
Chain CUSTOMFORWARD (1 references)
pkts bytes target prot opt in out source destination
4860 3151K OVPNFORWARD all -- * * 0.0.0.0/0 0.0.0.0/0
root@ipcop:~ # iptables -nvL BLUE_INET_ALLOW
iptables: No chain/target/match by that name
root@ipcop:~ #
... and that's the status again. It seems like we're on the right track, but I wonder if IPCop is doing things a bit differently that one would expect. Almost as if the system is processing our rules first, then processing the built-in rules and overriding our new settings with the stock configuration.
Again, I'm working towards a better understanding of Linux, but I'm not there yet.
OK, set the rc.local file back to stock and copied the new text into the rc.firewall.local.
VPN working OK now?
Quote:
Again, I'm working towards a better understanding of Linux, but I'm not there yet.
I've been working at it 4 years. Still learning ...
It's not obvious to me what is going on. I think it is now trouble shooting time. I believe it is the script /usr/local/bin/openvpnctrl that is putting the existing rule in CUTOMFORWARD, so it would seem the rc.firewall.local script is getting executed.
The way I would proceed to troubleshoot this is to copy rc.firewall.local to a dummy file
Code:
cp -p /etc/rc.d/rc.firewall.local testfile
and use your favorite text editor to delete the two lines in testfile (in your current directory) calling openvpnctrl (so we don't repeat what has already been done) and, as root type:
Code:
./testfile start
If there are no errors, check the contents of the CUSTOMFORWARD and BLUE_INET_ALLOW chains again.
This is basically free-for-all troubleshooting mode, so feel free to jump in with any troubleshooting ideas that you feel comfortable trying.
Last edited by blackhole54; 10-07-2007 at 12:15 AM.
Reason: minor wording change for clarity
With the rules we created in place, the VPN would _not_ start automatically on boot. However, it was not broken, because if I entered the web interface on IPCop and started it up, all the VPN tunnels would work fine. I removed our rules and rebooted the box again, and the VPN now starts up automatically again. Odd...
I coped the text to testfile, just as you suggested. For keeping things simple to start with, I also commented out all of our lines except the CUSTOMFORWARD line to drop all packets from BLUE except those bound for RED. Ran the testfile script. Here's the resulting iptables output:
Code:
login as: root
root@192.168.0.1's password:
Last login: Mon Oct 8 10:47:56 2007 from 192.168.0.102
root@ipcop:~ # cd /etc/rc.d
root@ipcop:/etc/rc.d # iptables -nvL CUSTOMFORWARD
Chain CUSTOMFORWARD (1 references)
pkts bytes target prot opt in out source destination
36178 30M OVPNFORWARD all -- * * 0.0.0.0/0 0.0.0.0/0
root@ipcop:/etc/rc.d # iptables -nvL BLUE_INET_ALLOW
iptables: No chain/target/match by that name
root@ipcop:/etc/rc.d # ./testfile start
root@ipcop:/etc/rc.d # iptables -nvL BLUE_INET_ALLOW
iptables: No chain/target/match by that name
root@ipcop:/etc/rc.d # iptables -nvL CUSTOMFORWARD
Chain CUSTOMFORWARD (1 references)
pkts bytes target prot opt in out source destination
40552 34M OVPNFORWARD all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 DROP all -- eth1 !eth2 0.0.0.0/0 0.0.0.0/0
root@ipcop:/etc/rc.d #
The BLUE_INET_ALLOW is intentionally left out at this point. I'll re-enable and tweak on that chain at some point in the future.
Tried to ping a known host on the Orange LAN from a host on BLUE: no reply. Bingo!
So thing brings me to a question:
Should we set something in place to simply run the testfile script after boot?
I seems we had everything correct, but for some reason adding the rule to the rc.firewall.local caused some odd behaviors.
At this point we have essentially succeeded, functionally, but I would like to figure out a way to run the testfile script after boot, unless there is a better way?
Thank you again for your precise instructions and tremendous help.
With the rules we created in place, the VPN would _not_ start automatically on boot. However, it was not broken, because if I entered the web interface on IPCop and started it up, all the VPN tunnels would work fine. I removed our rules and rebooted the box again, and the VPN now starts up automatically again. Odd...
Quote:
I seems we had everything correct, but for some reason adding the rule to the rc.firewall.local caused some odd behaviors.
At this point we have essentially succeeded, functionally, but I would like to figure out a way to run the testfile script after boot, unless there is a better way?
I would say your characterization of the situation is spot on. It would be nice to figure out what is really going on here and then do things correctly. I would suggest googling to see if you could find anything of use, but offhand I can't think of search terms that might be likely to yield something.
I did notice something odd in your last post. The CUSTOMFORWARD chain contained only one rule referencing VPN. The first time you posted the rules (before we started changing things), there were two such rules.
I can think of one ugly hack that might work to allow a work around unless and until a proper fix can be found. That would be to add a line similar to the following to /etc/rc.d/rc.local:
This waits 60 seconds (adjust time as needed) and then executes the testfile. The ampesand at the end "backgrounds" the process so that rc.local continues (and eventually exits) w/o waiting. Be sure to note the spaces after the opening brace and before the closing brace. Besides being a rather crude brute force, my concern about this (w/o really understanding what is going on with bringing up the rest of the firewall) is that IPCop may at some point(s) give rc.firewall a reload command, which would reconstruct the firewall from the ground up and leave you w/o your new rule(s).
If you want to continue experimenting to try to figure out why adding the rules to rc.firewall.local failed, I can think of two things, each involving logging something about that script. The first would log everytime rc.firewall.local is called and what the parameter is. You could, at the top of the file include (in red):
Code:
!/bin/sh
# Used for private firewall rules
LOG_FILE=/var/log/rc.firewall.local.time_stamps
touch $LOG_FILE
chmod 644 $LOG_FILE
echo "$(date) rc.firewall.local called with parameeter: $1" >> $LOG_FILE
The other thing you could try is using the set -x bash command to list the commands as they execute to standard error (stderr), and then log stderr, which would log all commands that execute along with any errors.
Code:
/bin/sh
# Used for private firewall rules
LOG_FILE=/var/log/rc.firewall.local.trace
touch $LOG_FILE
chmod 644 $LOG_FILE
exec 2>> $LOG_FILE
set -x
Last edited by blackhole54; 10-08-2007 at 11:30 PM.
Reason: typo cleanup
I did notice something odd in your last post. The CUSTOMFORWARD chain contained only one rule referencing VPN. The first time you posted the rules (before we started changing things), there were two such rules.
That puzzled me for a minute, then I remembered that OpenVPN had been enabled on blue (but not needed) so I disabled that within the web interface.
As for googling for answers here, I've been there. It seems to me that the general population of IPCop users are not "hacking the box" for customized behaviors beyond add-ons and such. I have found very little information covering "under-the-hood" customizations. People who want a truly custom firewall solution would tend to build one from scratch, perhaps?
I just find both the interface and feature set of IPCop to be perfect for our needs... (except for the cross-talk between interfaces, of course!)
I don't suspect that the box will re-load the rules dynamically, but what I can do to find out is just leave it alone and let it run for a while, and periodically test pinging from blue to orange. If the behavior of dropping those pings remains constant, I'll attempt to implement what you call an "ugly hack".
I had this box (an old Gateway NS-7000 SCSI-based server) up and running for 165 days with no reboot until I decided to go messing around and try to hack it! If the rule stays put in iptables for 5 months at a time, I'm OK with that.
It's been a day or two now since I ran the 'testfile' script. I'll check the box in the morning to see if the pings are still being dropped.
Thanks again for the advice. I'll post back with results when I have them.
As for googling for answers here, I've been there. It seems to me that the general population of IPCop users are not "hacking the box" for customized behaviors beyond add-ons and such. I have found very little information covering "under-the-hood" customizations. People who want a truly custom firewall solution would tend to build one from scratch, perhaps?
I just did a little googling with the search terms rc.firewall.local (in quotes since Google is funky with punctuation marks) and ipcop. There are definitely people posting about customizations of IPCop. (I guess it's easier to solve a problem when you already know the answer ... in this case the name of the file.) I was looking to see if anybody was having the kind of trouble you are with the rules placed in rc.firewall.local mysteriously vanishing and screwing up VPN. I found nothing. People just seemed to be making changes to that file and it works as expected. I even wondered if it was some weird interaction with your VPN, so I added the search term openvpnctrl. I still found nothing in way of explanation.
Quote:
I don't suspect that the box will re-load the rules dynamically, but what I can do to find out is just leave it alone and let it run for a while, and periodically test pinging from blue to orange. If the behavior of dropping those pings remains constant, I'll attempt to implement what you call an "ugly hack".
My guess is the most likely time for reloading the rules are when certain changes are made via the web interface. In my brief romp through GoogleLand, I noticed discussion about which version the reload option in rc.firewall.local was added. So I think it is in there for some reason. If you want to pursue that "ugly hack," you could monitor forthe rule disappearing and replace it if that is discovered. The cleanest way to do that would be with cron, but I don't know if IPCop has that capability. You could also background a continuously running script that does the same check but uses the sleep command to pause between loops. I will note that that is not considered the proper way to implement a daemon (which is what it would in effect be), but I don't have enough knowledge or experience to advise you how to do that properly.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
I didn't realize it was going to enumerate every address like that! I also was unaware of the 25000 byte limit, but I guess you have to have some limit. For future reference, when you post computer output, it will be easier to read if you rap "code tags" around it. (That will cause everything to line up the way it was originally, and prevent weird "smilies" from showing up in the middle of it.) You can do this by highlighting the text and pressing the hash mark (#) above your edit box. Or you can do what I usually do and just type them in manually. (Use the hash mark in the toolbar to find out what they are if you don't know.)
... in this case the name of the file.) I was looking to see if anybody was having the kind of trouble you are with the rules placed in rc.firewall.local mysteriously vanishing and screwing up VPN. I found nothing. People just seemed to be making changes to that file and it works as expected. I even wondered if it was some weird interaction with your VPN, so I added the search term openvpnctrl. I still found nothing in way of explanation.
