On Sunday 05 January 2003 05:37 pm, Tommy McNeely wrote: > Thanks for your quick answer on the ftp port issue (I learned a new > command "modinfo" that will make it so I can answer module questions > on my own from now on) > > I have my wireless network being "firewalled" by my Linux box... > (something like) > > :INPUT DROP [0:0] > > (definitions removed) > > [0:0] -A INPUT -i lo -j ACCEPT > [0:0] -A INPUT -i eth0 -j ACCEPT > [0:0] -A INPUT -i eth1 -j PublicFilter > [0:0] -A INPUT -i eth2 -j WirelessFilter > [0:0] -A INPUT -i ppp+ -j PublicFilter > > (excess rules removed) > > ##### WIRELESS FILTER > [0:0] -A WirelessFilter -p udp -m udp --dport 53 -j ACCEPT > [0:0] -A WirelessFilter -p tcp -m tcp --dport 53 -j ACCEPT > [0:0] -A WirelessFilter -p tcp -m tcp --dport 80 -j ACCEPT > [0:0] -A WirelessFilter -p udp -m udp --dport 67 -j ACCEPT > [0:0] -A WirelessFilter -m mac --mac-source (censored) -j ACCEPT > [0:0] -A WirelessFilter -m mac --mac-source (censored) -j ACCEPT > [0:0] -A WirelessFilter -m mac --mac-source (censored) -j ACCEPT > [0:0] -A WirelessFilter -m state --state RELATED,ESTABLISHED -j ACCEPT > [0:0] -A WirelessFilter -m state --state NEW -j MyREJECT > Basically what I am trying to accomplish here is that _IF_ you figure > out my key (which I know is trivial) and know the name of the ESSID > (which is not being broadcast), then I want to have a little firewall > waiting for you on the other side. > > I _DO_ want to allow them to come online and be able to look up their > DNS (so windows thinks its online)... but I want to have it so that > only my machines have full access to the network, and people who dont > have access (should be my friends that I have given ESSID and KEY to) > will get a webpage that says something generic like "You are on such > and such wireless network.. If you do not have permission to be here, > get off now.. otherwise, please email wirelessadmin@somedomain.com to > be added to the access list." > > My problem is.. that while I feel the actual firewall HOST is > protected by the rules below, I don't have any fricken clue how to do > the redirect thing to the web site.. and I think I probably need some > freakey forward rules or maybe something in -t nat? and squid?? or ?? > maybe a neat virtual host in apache?? What you have listed here is only for INPUT chain, therefore only for connections directly to your firewall host. Anything that requests an IP other than the firewall's will go through the FORWARD chain, never hitting INPUT except one possible situation I'll mention in a bit. You want to allow/prevent connections in the FORWARD chain, filter table (default table) for anything other than connections TO this box. For connections directly to this box, use the INPUT chain. For your scenario, I would suggest something a little unusual, as follows. Set up that the first rule (for eth2) in NAT PREROUTING jumps to a user-defined chain. In that chain, have an ACCEPT rule for anyone on your access list, and use the REDIRECT target for the rest (from eth2), to redirect them to an apache-served document on the box itself. You can redirect to a different port and set up a virtual host if you are already using apache. Also ACCEPT UDP 53 if you want them to be able to use DNS regardless of the access list, in the PREROUTING chain. NAT PREROUTING is explicitly for NAT, NOT for filtering, but this usage is valid, IE using the ACCEPT target to control what packets hit DNAT or REDIRECT rules. You will then need to ACCEPT those connections in INPUT for them to be able to complete the REDIRECT, and ACCEPT access list clients in FORWARD to allow them out to the internet or the rest of your network. This is the situation I hinted at where normally forwarded connections will hit the INPUT chain, since after a redirection they are destined for the local box. I'd also suggest logging right before the REDIRECT, so if you see someone connecting again and again but NOT complying with your request, you can add a DROP rule in FORWARD and INPUT to just shut them out. (actually, depending on paranoia level and traffic level, you might want to log all state NEW connections from eth2...) Finally, if you write the rules carefully, you should be able to reuse the WirelessFilter chain from PREROUTING, INPUT and FORWARD. Normally this poses problems, but if all the rules in the chain consist solely of matching macs and accepting, and other rules are not in that chain, it will work. This way you could have something like: iptables -A WirelessFilter -m mac --mac-source (censored) -j ACCEPT iptables -A WirelessFilter -m mac --mac-source (censored) -j ACCEPT iptables -A WirelessFilter -m mac --mac-source (censored) -j ACCEPT iptables -t nat -A PREROUTING -i eth2 -p tcp --dport 53 -j ACCEPT iptables -t nat -A PREROUTING -i eth2 -p udp --multiport \ --dport 53, 67 -j ACCEPT iptables -t nat -A PREROUTING -i eth2 -j WirelessFilter iptables -t nat -A PREROUTING -i eth2 -j LOG --log-prefix \ "IPT:UnAuthWrls:" iptables -t nat -A PREROUTING -i eth2 -j REDIRECT --to-ports 83 iptables -A FORWARD -i eth2 -p tcp --multiport --dport 25,80,110,443 \ -j WirelessFilter iptables -A INPUT -i eth2 -p tcp --dport 83 -j ACCEPT iptables -A INPUT -i eth2 -m state --state ESTABLISHED,RELATED \ -j WirelessFIlter With this you accept the stated ports in PREROUTING regardless of source mac, then accept your access list macs in WirelessFilter regardless of port, then redirect everything else to local port 83, where you (presumably) have apache configured to deliver your little message. Remember that all this does is control what packets reach the REDIRECT, it is not intended to filter what packets are allowed/disallowed. The log-prefix can be anything you want, but make it something meaningful and easy to search. (IE, "cat /var/log/messages | grep IPT:UnAuthWrls") You could of course just redirect port 80 requests, but who cares? This way anything other than the previously accepted ports gets redirected, if the result is nonsensical it's their problem, won't affect you. :^) You can of course redirect to port 80 if you want, but although it is possible to redirect without any '--to-ports' your safer forcing everything to a single port that you can control more easily. REDIRECT will automatically reverse, just like SNAT and DNAT, so the response will appear to the client as coming from the expected port anyway. As long as WirelessFilter's rules are 'safe', (nothing table-specific) you can then reuse the WirelessFilter user-defined chain in FORWARD to handle ACCEPTs for everyone on the access list, provided that the packet matches one of the ports in the rule that jumps to WirelessFilter. If there is some reason those people would need to access the firewall host itself, then you could reuse the chain again in INPUT, where you will also need a rule to ACCEPT port 83 (or whatever you redirect to) so that anyone can reach the message. You should use state matching rules in INPUT and FORWARD chains still, to allow ESTABLISHED and/or RELATED connections where appropriate, (you might not want RELATED nor even ESTABLISHED for the redirects...) but this wouldn't serve any useful purpose I can see in the PREROUTING chain. The point is simply to ACCEPT allowed connections in PREROUTING so that everything else drops through to the REDIRECT, don't try to do any 'real' filtering in the PREROUTING chain or one to which it jumps. Be careful about EST/REL for unauthorized connections, though, you really shouldn't need them. Obviously there are several vital rules missing from the fragments I offer above, and the fragments themselves would need to be changed to match your actual needs, but they should convey the idea well enough. j
