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
Attachment:
signature.asc
Description: Digital signature