DHCP through transparent bridge
Hi all, I am completely stuck with getting my transparent bridge working correctly. The aim is to create a bridge that will have our LAN on its internal port, and a switch on the external port into which I can plug in suspect machines. If I can get this working, the following script will only permit DNS, ICMP pings, and HTTP through so any self propagating virri / worms will not infect the rest of my lan. At this point, I can then use the network to download updated virus definitions and any patches to fix the machines. It is all working fine as long as my client on the external interface (i,e the infected machine) has a static IP.... but this is not ideal. How can I ammend the following script to allow DHCP through so the client can get all its IP / default route etc from my DHCP on the internal segment ???? I thought that DHCP used UDP ports 67 + 68 although I could be wrong... The client machines are all Windows XP if that makes any difference... Any suggestions or ideas are greatly appreciated. Richard My script follows. ------------------------ #!/bin/bash # Set which is internal and external interfaces here... INT="eth0" EXT="eth1" IPTABLES="/usr/sbin/iptables" modprobe ip_conntrack modprobe ip_conntrack_ftp iptables -F # Drop dodgy packets $IPTABLES -I FORWARD -m state --state INVALID -j DROP # Accept packets relating to an outgoing connection $IPTABLES -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT # if packet starts on internal network, accept it $IPTABLES -A FORWARD -m physdev --physdev-in $INT -j ACCEPT # Permit pings through $IPTABLES -A FORWARD -p icmp -m limit --limit 4/s -j ACCEPT # DHCP ... $IPTABLES -A FORWARD -m physdev --physdev-in $EXT -p udp --dport 67 -j ACCEPT $IPTABLES -A FORWARD -m physdev --physdev-in $EXT -p udp --dport 68 -j ACCEPT $IPTABLES -A FORWARD -m physdev --physdev-in $EXT -p tcp --dport 67 -j ACCEPT $IPTABLES -A FORWARD -m physdev --physdev-in $EXT -p tcp --dport 68 -j ACCEPT # Allow DNS requests through.... $IPTABLES -A FORWARD -m physdev --physdev-in $EXT -p udp --destination-port 53 -j ACCEPT # Other specifics # CUSTOM RULES HERE..... $IPTABLES -A FORWARD -m physdev --physdev-in $EXT -p tcp --destination-port 80 -j ACCEPT $IPTABLES -A FORWARD -m physdev --physdev-in $EXT -p tcp --destination-port 443 -j ACCEPT # IF THE BRIDGE HAS BEEN ASSIGNED AN IP, THEN THIS LOCKS DOWN WHO CAN CONNECT $IPTABLES -A INPUT --in-interface br0 -s 10.0.0.62 -d 10.0.0.63 -j ACCEPT $IPTABLES -A INPUT --in-interface br0 -d 10.0.0.63 -j DROP # drop everything else $IPTABLES -A FORWARD -m physdev --physdev-in $EXT -j DROP
Richard wrote regarding '[SLE] DHCP through transparent bridge' on Fri, Aug 06 at 09:29:
Hi all, I am completely stuck with getting my transparent bridge working correctly. The aim is to create a bridge that will have our LAN on its internal port, and a switch on the external port into which I can plug in suspect machines. If I can get this working, the following script will only permit DNS, ICMP pings, and HTTP through so any self propagating virri / worms will not infect the rest of my lan. At this point, I can then use the network to download updated virus definitions and any patches to fix the machines.
It is all working fine as long as my client on the external interface (i,e the infected machine) has a static IP.... but this is not ideal.
How can I ammend the following script to allow DHCP through so the client can get all its IP / default route etc from my DHCP on the internal segment ????
I thought that DHCP used UDP ports 67 + 68 although I could be wrong... The client machines are all Windows XP if that makes any difference...
Any suggestions or ideas are greatly appreciated.
[... script trimmed...] Why not just run another DHCP server that only listens on the "safe" interface, and do the NAT thing on the LAN interface? If all you need is to be able to download patches, just put the infected machine on a second isolated network and allow http/ftp through a NAT'ed gateway instead of messing with a bridge. :) That also gives you a second test network to play with later on, while you're testing other network devices, etc. --Danny, doing just that here
participants (2)
-
Danny Sauer
-
Richard Curtis