On Wed, Oct 10, 2001 at 11:37:36AM -0400, Mike Dresser wrote: > Greetings, > > Apologies for the length of this, I'm just running some thoughts through > my mind on a setup I have here. > > I have a machine, X, 192.168.10.5, that has two modems in it. One > modem, /dev/ttyS2, dials into Y, 192.168.0.3 as needed, and the other, > /dev/ttyS0, into the Internet. > > I want to deny ports 23, 37,137,139, etc, from the Internet, but allow > them from Y. > > So i setup > > /sbin/ipchains -I input -i ppp+ --destination-port=23 -p tcp -j REJECT > > So as expected, this blocks port 23 on both ppp interfaces. > > Now, since ppd 2.3.11 doesn't have the unit command, there's a > possiblity that the interfaces could get flipped around, ppp0 being ppp1 > and vice versa, it all depends on whether a link is up or not when the > other tries to get out. So a simple -i ppp0 on the internet interface > won't work, cause it could be ppp1 at random > > Now, I have two choices. > > if [ $DEVICE == "/dev/ttyS2" ]; then > /sbin/ipchains -I input -i $IFNAME --destination-port=23 -p tcp -j > ACCEPT; > fi > > in my /etc/ip-up.d/00fw > > or i can > > /sbin/ipchains -I input -i ppp+ -s 192.168.0.0/16 --destination-port=23 > -p tcp -j ACCEPT > > My question is, lets say I have a service on 23, that's vulnerable to > scrptkiddie.c. Assume a properly crafted packet can overflow it, and > open a rootshell on port ... 911. Can a spoofed packet be sent over the > 69.69.69.69 interface, that says its source packet is 192.168.0.3, which > would be allowed through, causing this hypothetical exploit? This hypothetical exploit shouldn't be allowed to exist in the first place. If you have a service on port 23 vunerable to scriptkiddie.c that service needs to be immeadiatly replaced with one not vunerable. A firewall is a last line of defense, you should never rely entirely on any one security solution. Also, the iproute package allows renaming of an interface, I'm not sure what affect this would have on a dynamicly created interface, but it would be worth investigating as a possible way to insure the ppp devices have the desired names. > > The second ipchains option seems a bit cleaner to me, but obviously no > good if the above situation is possible. If the ipchains table is > reset when either interface comes up, I suppose the rules will go away > from the /sbin/usr/ipmasq if it's the wrong connection on the pppX > interface, so the first ipchains should be possible > > I suspect I've missed something somewhere in my understanding of > firewalling, is all. > > Comments? > > Thanks, > Mike > > > -- > To UNSUBSCRIBE, email to debian-firewall-request@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Attachment:
pgpdRTCPJO74q.pgp
Description: PGP signature