>>>>> ":" == Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx> writes: :> Hello, Alex Feldman a écrit : >> I know nothing about ipchains. :> Fine, here we're talking about iptable, the successor of :> ipchains. :-) Right, but evry tutorial or FAQ I pick up seems to refer back to ipchains, an I wanted to discourage people from ding that here. >> iptables -A INPUT -p udp -i eth0 --sport 53 --dport 1024:65535 -j >> ACCEPT iptables -A INPUT -p tcp -i eth0 --sport 53 --dport 1024:65535 >> -j ACCEPT :> These two rules are possibly harmful : they allow any incoming packet :> to a non privileged local port from any host using source port :> 53. Better deal with DNS replies in the generic rule allowing :> established/related connections. Yes, good point. Even if they aren't harmful, that's a better way to do it. >> iptables -A INPUT -p tcp -i eth0 --dport 80 --sport 1024:65535 -m >> state --state NEW -j ACCEPT >> >> #--------------------------------------------------------------- >> # Allow previously established connections >> #--------------------------------------------------------------- >> iptables -A INPUT -j ACCEPT -m state --state ESTABLISHED,RELATED -i >> eth0 -p tcp :> Don't restrict this rule to TCP. It's also needed for other protocols :> : DNS replies using UDP, ICMP ping and traceroute replies, ICMP :> signalling messages... Again, good point. Thanks. >> ********************************************************************* >> >> Some of this I copied off the web, and I do not understand why I need >> all of it, e.g., all the 1024:65535 port identifiers. :> "--sport 1024:65535" means that connections to your services should :> are expected to come from unprivileged source ports, which is usually :> true. However it's not really useful. Good. Thanks. >> However, I would like to open up the computer further, maybe not all >> the way but for the moment that would be OK, to my own laptop via its >> mac address - I figure that would be pretty safe, but if not, I'd >> like to hear why not. :> It is not safe because it is very easy to spoof a MAC address. OK. This was just for use around the house, but it didn't work anyway, see below. >> So I added the line: >> >> iptables -A INPUT -m mac --mac-source XX:XX:XX:XX:XX:XX -j ACCEPT >> >> and some variations on it, like with "-p all" in there, at various >> places in the file, but none of them worked (and they all had my real >> mac address in there, I just took it out before I displayed this to >> the world). :> Be aware that this will work only when the client and the server are :> on the same network (link layer). MAC addresses don't go through :> routers. And apparantly the wireless box I have that the phone company sold me does this. I thought it wouldn't be a problem, since I treat the house as one segment, but apparantly it is. >> especially since the basic file seems to work even though the first >> thing I do is drop all input, and then allow some back later. :> No, you don't drop first then allow later, else nothing would :> work. The first three commands (--policy or -P) just set the default :> policy of the chains to DROP. The default policy tells what to do :> when the packet doesn't match any rule with a "terminal" target and :> reaches the end of the chain. So it's rules first then default :> policy, regardless of the location of the --policy commands in the :> script. Thanks, I finally figured this out, and it is nice to have it further clarified. OK, so here is my idea now: Open up the computer to port 22 for a ssh connection, with keys that I put on my computer at home and my laptop. THen I can ssh in, securely. The risk is that I leave my laptop somewhere, there would be no way to get in without that key. Once in via ssh, I would open up a few other ports via ipchains to let me get my IMAP mail or whatever else, and then close them right back down again. That seems simple enough. Thanks very much - this has been very halpful. -- --alex alex@xxxxxxxxxxxxxxxxxxx <a href="http://math.boisestate.edu/~alex/">Alex Feldman</a>