Re: Block martians with source address 127.0.0.1

From: Bjørn Rasmussen (bjoernr_at_sensewave.com)
Date: 06/01/04

  • Next message: Bjørn Rasmussen: "Re: Block martians with source address 127.0.0.1"
    To: Ross Vandegrift <ross@willow.seitz.com>
    Date: Tue, 01 Jun 2004 13:48:44 +0200
    
    

    man, 31.05.2004 kl. 18.14 skrev Ross Vandegrift:
    > On Mon, May 31, 2004 at 12:55:52PM +0200, Bj?rn Rasmussen wrote:
    > > I added these rules as the only ones to the input chain on my
    > > LAN-interface:
    > >
    > > iptables -A INPUT -i eth0 -s 127.0.0.1 -j LOG
    > > iptables -A INPUT -i eth0 -s 127.0.0.1 -j DROP
    > > iptables -A INPUT -i eth0 -s -j LOG
    > > iptables -A INPUT -i eth0 -s -j DROP
    >
    > I'd change the source address to 127/8 - the whole class A is no-go for
    > external traffic.
    >
    > > >From a client on my LAN, I used the command "nmap -e <LAN-interface on
    > > client> -S 127.0.0.1 <ip-addr. of firewalls LAN-interfac>" to spoof the
    > > localhost address.
    > >
    > > The kernel on the firewall logs these packets as martians which it
    > > should do, but my rules will not log or block these packets. Anybody
    > > who knows how to do it? Is it possible? I guess there are situations
    > > were malicious persons could at least perform a DoS-attack?
    >
    > Two things could be going on:
    >
    > 1) You have rp_filter turned on, which causes the kernel to ignore any
    > incoming packets not addressed to that box, or not originating on a connected
    > network.

    I've turned it off, because I use FreeS/WAN (sorry forgot to tell you).
    >
    > 2) You've probably stuck the above rules to kill martians on the external
    > interface, but when you test from an internal host, packets will arrive via
    > the internal interface, and therefore bypass your iptables rules. Try adding
    > those rules to the other ethernet interface as well.

    These rules were added temporarily for testing on my firewalls internal
    interface "eth0".

    >From another response I've got, it looks like the kernel silently drops
    incoming packets with source addresses of itself.


  • Next message: Bjørn Rasmussen: "Re: Block martians with source address 127.0.0.1"

    Relevant Pages

    • Terminal Server Setup
      ... description GRE Tunnel Source Interface ... input packets with dribble condition detected ... output buffer failures, ... Serial1/0 is up, line protocol is up ...
      (comp.dcom.sys.cisco)
    • Re: Tuning ADSL lines on Ciscos roputer - LONG -
      ... Last clearing of "show interface" counters never ... minute input rate 0 bits/sec, ... input packets with dribble condition detected ... output buffer failures, ...
      (comp.dcom.sys.cisco)
    • Re: Terminal Server Setup
      ... description GRE Tunnel Source Interface ... input packets with dribble condition detected ... output buffer failures, ...
      (comp.dcom.sys.cisco)
    • Re: Excessive interface resets on Cisco 1841 and FIOS line
      ... huge amount of interface resets on the WAN interface, ... access-list 4 remark HTTP Access-class list ... input packets with dribble condition detected ... output buffer failures, ...
      (comp.dcom.sys.cisco)
    • Dell PowerEdge 850 bge(4) RELENG_6 (WAS: Re: bge(4) problem)
      ... But I have a problem with two dual port Broadcom cards plugged in into ... I cannot connect them to the 1000MBit switch (a Dell Powerswitch, ... the link speed negotation / interface link state change problems you describe on this platform persist. ... This number does not increment on these syn packets. ...
      (freebsd-current)