oops only read half the thread. Sorry about that.
Daniel
>Just a few quick points...there is no clear indication of who said what so
>don't attribute any quoted material to anyone.
>
>> -----Original Message-----
>
>> On Mon, 13 Mar 2000, dan Harrison wrote:
>>
>> > Once you tell an attacker what protocol and port you don't want to
>> > talk on they know where to focus their attacks.
>[snip]
>
>This misses the point. We're talking about networks where we _don't_ have an
>ident server. The ONLY reason to send back a TCP RST is to make the remote
>mail daemon give up more quickly. It's not protecting anything so an
>attacker can't draw any conclusions - getting a RST back on port 113 when
>everything else gets silently discarded only tells you that the network
>admin is vaguely clueful.
>
>> >
>> > Daniel
>
>> > >they close down their end of it. It's considered good
>> net-etiquette to
>> > >rst the otherside when possible...
>
>The RFC (793) behaviour for non-screened TCP stacks is to send a RST for
>packets that head for ports where they aren't wanted. This allows the remote
>TCP stack to get out of SYN_SENT, correct. Most implementations don't hang
>around in SYN_SENT for very long though.
>
>
>> > >> Any disadvantages for using service reset inbound vs.
>> standard behavior of
>> > >> silently dropping connections?
>
>For ident, yes. It makes mail go through much more quickly to hosts that run
>identd. I have had cases where the ident response wait was so long that the
>local mailservers decided that the connection had timed out - this caused
>all sorts of problems up to and including total failure of mail delivery to
>certain broken networks.
>
>[snip]
>> > >> > > > > Don't know how to set it up in pix, but what
>> > >> > you have to do is to
>> > >> > > > >REJECT the packets instead of DENYING them. DENY simply
>> > >> > drops them and
>> > >> > > > >REJECT drops them AND sends the client an ICMP
>> > >> > destination-unreachable
>> > >> > > > >packet.
>
>Not quite. REJECT sends a TCP RST. Normal filtering routers would send an
>ICMP 3/13 (Administratively Prohibited) packet which won't always get to its
>destination. Most filtering routers will need to be explicity configured not
>to send an ICMP error message if there is traffic to a filtered port. Cisco
>for example have the "no ip unreachables" interface command to do this.
>
>On a "normal" Cisco you can get this REJECT behaviour by _permitting_ the
>traffic as long as your mail server doesn't run identd. This sucks a bit
>from a security angle. If you're using NAT then you can be more elegant by
>having a NAT mapping for port 113 on all mailserver IP addresses that points
>to a "safe" host (I tend to use the router itself) whose TCP stack you trust
>to send back a TCP RST in the face of adversity and nasty packets.
>
>Cheers,
>
>--
>Ben Nagy
>Network Consultant, CPM&S Group of Companies
>PGP Key ID: 0x1A86E304 Mobile: +61 414 411 520
>-
>[To unsubscribe, send mail to [EMAIL PROTECTED] with
>"unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
