Mailinglist Archive: opensuse-security (192 mails)

< Previous Next >
Re: [suse-security] IPChains
  • From: Steffen Dettmer <steffen@xxxxxxx>
  • Date: Mon, 29 May 2000 12:36:42 +0200
  • Message-id: <20000529123642.F2640@xxxxxxxxx>
* Gerhard Sittig wrote on Sun, May 28, 2000 at 22:24 +0200:
> On Sun, May 28, 2000 at 18:07 +0200, Steffen Dettmer wrote:
> > * Gerhard Sittig wrote on Sat, May 27, 2000 at 22:18 +0200:
> >
> > Why should this happen? I would assume, that kids would think
> > they hit a machine that is currently down or unused IP/DNS
> > Name.
>
> Portscanning a machine with some ports open and some denied (i.e.
> without reaction) will tell you there's some blocker in between,
> usually a packet filter.

Yepp, think so too.

> Of course denial slows the scan (it's
> running to timeouts instead of getting quick responses). But
> rejecting will make you subject to fingerprinting.

I found many scans are very slow, i.e. a port every 20 minutes or
so, to prevent IDS from working. What tells i.e. nmap when trying
to analyse fingerprints of your linux box?

> Although I'm not *that* sure of all these things, I simply got
> used to
> - pass the valid services
> - deny the others and
> - reject auth (tcp 113) only to not slow down SMTP delivery and
> others curious about these things (but still not relying upon
> them, so I don't break anything)

Yepp, at least ident should be rejected in my opinion too.

> Feel free to tell me I'm wrong, chances are quite overwhelming
> that I am. :) Luckily I'm just an average user and not a "real"
> admin. :>

Well, I think that is mostly a question of police. I found most
blocked accesses were misconfigurations or similar. I don't know
what an attacker win, if she knows that the packetfilter sends
ICMPs. The argument of delaying scans doesn't matter IMHO, since
you can use a parallel scan or whatever.

> Here's what I got from reading the ipfilter HowTo which has a lot
> of general firewalling stuff, too.
>
> Rejecting closed TCP ports and sending icmp-unreach for closed
> UDP ports and ICMP requests will make the machine look like it
> would without the filter.

I think this is wrong, at least for linux ipchains, since the
generated ICMP is of the type "communication administrativly
prohibited", which looks different from "connection refused". But
maybe some very stupid script kiddies wouldn't see this...

> Denying will reveal that there's
> something blocking, making the kids think "something's wrapped,
> it's precious and interesting for me".

Well, another argument: When they see a firewall, they know that
there are some security systems running. So they may decide to
attack networks without security systems first, since they see
there's no real chance to find a hole by scanning. If they search
for a DNS Server (most networks have one), and they get a block
for all ports they try to access, they know they don't need to go
on. If there are some addresses looking like a down machine, they
may decide to scan again next day.

> Fragmented ICMP packets aren't (necessarily) corrupted. But I
> had in mind an Bugtraq article of the last days where a cracker
> misused artificially wrongly fragmented ICMP to fool TCP stacks.

last days... mmm... Do you mean the jolt2 thing? IIRC this
wasn't a real fraqmentation style attack but a DoS, except for
Microsoft systems maybe.

> It seems to be necessary to always defragment everything on a
> firewall.

Of course, i.e. to prevent address rewriting by fraqmentations
offsets overwriting the IP Addresses.

> Trying to cut corners often turns out to fail sooner
> or later. And by employing path MTU discovery fragmentation
> should even become uncommon and avoidable.

Sorry, couldn't get this. You mean to prohibite MTU discovery?
This could slow down connections a lot, especially if you have a
"defragment always" firewall AFIAK.

> Maybe one even should
> drop fragmented packets in general,

Ohh, I don't think that this would work!

> as well as too short packets
> to be real and source routed packets

it's not so quite easy to drop too short packets I think. Telnet
may send packets with just one byte date for instance.

oki,

Steffen

--
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.

< Previous Next >
Follow Ups