[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Request for comments: iptables script for use on laptops.



Hi,

On Tue, May 23, 2006 at 07:29:44PM +0400, Konstantin Khomoutov wrote:
> On Tue, May 23, 2006 at 04:36:31PM +0200, Uwe Hermann wrote:
> 
> >>> useless. Did I miss anything?
> >> Kernel shoots any packet it considers as being "martian" -- e.g. packets
> >> from 127.0.0.0/8 cannot appear on any interface except lo.
> >> The same applies to the reverse case: no packet coming from "external"
> >> interface but claiming to be destined to 127.0.0.0/8 woun't be passed
> >> further by the kernel.
> >> 
> >> net/ipv4/conf/ethN/log_martians=1
> > Are you sure? log_martians does just that, it _logs_ such
> > packets/attempts, but it does not prevent them (at least the kernel
> > docs don't say so).
> Yes, this option just logs them.
> But they get logged when they are killed.
> 
> This behaviour, BTW, even forbids manual FORWARDing rules in iptables
> that redirect packets from "external" interfaces to lo. While the
> Netfilter framework will happily accept such rules, kernel will shoot
> packets forwarded this way since it sees a packet that came from external
> iface but is destined to localhost (which cannot occur).
> 
> This behaviour costed me several days to figure out while I tried to set
> up IPSec (openswan) + L2TP (l2tpd) server. The idea of this setup is
> that 1) IPSec virtual ifaces are coupled with real Inet ifaces; 2) After
> openswan did it's work, kernel sees "just IP" packes as if they were
> coming from the real Inet iface. We then should forward these packets to
> L2TP daemon, and the straightforward solution -- to bind l2tpd to the
> localhost -- simply doesn't work since l2tpd sees no packets: they are
> all killed by the kernel (as going from external interface and destined
> to localhost). The working solution is to put l2tpd to a LAN iface
> (another external one) and deny direct connections to in from that iface
> (only forwarded packets must reach).
> 
> I think you may be misguided (as I was) by the fact that packets to
> localhost are "destined to us" and must be accepted. But think of it:
> when some *other* host wants to send us a packet, it sends it to one of
> our "external" IP addresses, not to 127.0.0.1! And we get this packet as
> destined to that "external" IP. Packets destined to localhost can really
> be generated only by localhost. That's why it's called loopback, after
> all. ;-)
> 
> >> I think the best way to secure the box is the simplest: allow incoming
> >> packets with states ESTABLISHED and RELATED, deny all others (except for
> >> OpenVPN or whatever remote access is needed).
> > I fully agree. That's what I'm trying to do with my script. The only
> > other thing I let in is some types of ICMP packets...
> >> All special ICMP packets needed for proper functioning of TCP/IP (PMTU
> >> discovery for example) fall to the RELATED domain and are passed to the
> >> stack.
> > I currently have the below lines to handle ICMP. So are you saying I
> > could safely remove the last three lines, as they're already handled by
> > ESTABLISHED and RELATED?
> I'm not *surely* confident about this, but they must be counted as
> RELATED. My setups are based on this and it seems to work.
> 
> ESTABLISHED is only useful for TCP, it's not about ICMP.
> 
> P.S.
> Our conversation should better occur on the debian-security
> mailing list, I think. ;-)

Indeed :)


Uwe.
-- 
Uwe Hermann 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org

Attachment: signature.asc
Description: Digital signature


Reply to: