Re: Decent iptables script for bridging?
Matthew Palmer wrote: You need ebtables to manage bridge filtering, if I'm not mistaken. Only if you want to do link layer filtering. iptables works fine on a bridge. You can use pretty much any iptables script if you modify it to leave out the NAT rules and in the FORWARD chain replace -i/-o with -m physdev --physdev-in/physdev-out. If you use kernel 2.6.x, that is. For 2.4.x you can keep using -i/-o for the incoming/outgoing interfaces. But to do any filtering with iptables you will need the bridge-nf patch (which has been merged with the ebtables patch and is available at ebtables.sf.net) Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for comments: iptables script for use on laptops.
Hi, On Tue, May 23, 2006 at 10:02:33PM -0400, Michael Stone wrote: (E.g., want to be able to test without the complexity of an encryption layer, don't want overhead of encrypting both sides of a local connection, etc.) Aside from that, yeah, ip addresses shouldn't be used for authentication on untrusted networks. (Though they are useful as one layer of security, to mitigate the risk of vulnerabilities in the encryption routines.) Full ACK. It's one additional layer of security, but should never be relied upon alone. 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 signature.asc Description: Digital signature
Re: Request for comments: iptables script for use on laptops.
Hi, On Tue, May 23, 2006 at 10:01:46AM +0200, Rolf Kutz wrote: iptables -A INPUT -j ACCEPT -s 127.0.0.1 # local host iptables -A OUTPUT -j ACCEPT -d 127.0.0.1 Correct me if I'm wrong, but I think this would also allow incoming traffic from 127.0.0.1 to the eth0 interface. So somebody spoofing his IP address to appear to be 127.0.0.1 could send _any_ traffic to you and you would ACCEPT it, basically rendering the firewall useless. Did I miss anything? Maybe this: | echo 1 /proc/sys/net/ipv4/conf/all/rp_filter Um, no. The line is from my own script, but the one from George Hein (which I was referring to) does not have that line. 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 signature.asc Description: Digital signature
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 signature.asc Description: Digital signature
Re: Request for comments: iptables script for use on laptops.
Hi,
On Wed, May 24, 2006 at 06:52:59AM +0200, Mike Dornberger wrote:
So what can happen? {SYN,ICMP} floods, TCP RST attacks, but the last one is
then just guesswork (assuming the attacker can't see the real traffic at
192.168.0.0/24 else you already have a big problem). Am I missing something?
Unfortunately, it's very common for an attacker to be able to watch
local traffic if you're on a hostile network with your laptop, for
example...
I have a rule for spoofed localhost addresses, I took from someone else some
time ago at top of my INPUT chain:
iptables -A INPUT -d 127.0.0.0/8 -i ! lo -j DROP
Nice. There are probably more (similar) things you can do. I need to
read a bit more about how rp_filter and friends work. Isn't the above
already covered by rp_filter or some similar config option?
Hm, I often see people first cleaning/flushing/deleting the rules and then
setting the default policy. If the policy was for some reason set to ACCEPT,
you have a small time window when packets will be accepted, that got dropped
or rejected before by the rules you just deleted. Why not first set the
policy to DROP and then deleting rules?
Good point. But is the default policy deleted or reset after a
clean/flush/delete? If not, this is probably a good idea.
Something different I saw at various iptables scripts, that I don't quite
understand: Why do people put so much rules into the OUTPUT chain?
Easy - for increased security. With this approach I know exactly which
traffic will go out of my computer (on which ports).
Anything running on my computer trying to use some other port is logged.
I can then decide whether I just missed a rule (i.e. it's valid traffic)
and adapt the script accordingly, or if it's some nasty application,
trojan, rootkit, spyware, whatever which tries to phone home...
For example, I remember having heard of a version of Adobe Acrobat
Reader (for Linux) secretly connecting to some obscure Adobe server and
sending some information (don't know whether it was a fake or not)...
This kind of stuff can (sometimes) be prevented by filtering OUTPUT.
Another example: I don't want to _ever_ use unencrypted POP3 to fetch
emails, so I block that port. Now I simply cannot do that mistake, not
even by accident.
For
single user workstation/notebooks it hinders yourself a lot. E. g. you allow
access to some services like HTTP or SSH on other hosts. But what if you
want to connect to host that has that service running on an unusual port?
You then need to tweak you iptables script as root...
Exactly :)
Is it because you don't trust the software that is running?
That's one of the reasons, yes. Trust noone ;)
Especially since
this is a Debian mailing list here: You have the sources. If a service can't
bind to only 127.0.0.1, change it!
True. Still, sometimes you (or your local users) might run software you
don't know, didn't check, or which is simply closed-source. Again, a
firewall might help here in certain situations.
Or is it because you don't trust the other users there?
That can be another reason. Trust noone ;)
Why do they have an
account then or a computer that is connected to the internet (assuming you
don't want them to surf or run some file exchange/p2p service)?
Sometimes they want/need an account. If you don't (fully) trust them, you can
limit the amount of damage they can do somewhat. One method for doing so
is a firewall.
Once you
allow a user to just connect to a single port out there, he might start to
tunnel stuff if he really wants to do something else...
True.
(ssh over HTTP someone?)
Or ssh over DNS.
Maybe blocking something in OUTPUT is reasonable for servers as a stumbling
block if a service got taken over but then it probably won't be long until
the intruder got root access there and removes the rules anyway.
True. Of course, it's not a complete now we're 100% safe method,
but it helps prevent _some_ problems.
Cheers, 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
signature.asc
Description: Digital signature
Re: Error in debian package dia
Hi, thanks for your report. Sedlak Anton wrote: Your dia-common_0.94.0-7sarge3_all.deb has error in data.tar.gz (bad crc) for very long time - more then month. Due that this file is each day mirrored again and again. Unfortunately, I can't do much about this directly. The security team who created the file is informed for some time now and will probably react when it is due. Roland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
