opening up an ipchain

[Alex Feldman]

>>>>> ":" == Pascal Hambourg <pascal.mail at plouf.fr.eu.org> 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 at math.boisestate.edu

        <a href="http://math.boisestate.edu/~alex/">Alex Feldman</a>