Actually, if I recall that thread totally, doing a drop of the packets to
port 113 will perhaps cause smtp and perhaps a few other services to at
the least, experience delays, it not total timeouts. Better to rst on
idents.
Thanks,
Ron DuFresne
On Mon, 17 Jul 2000, Dean A. Luethje wrote:
> The following information is excerpted from a similar thread that occurred
> some time back...I hope that it helps!
>
> >[snip]
> >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.
>
> In the final analysis, I would say that simply dropping the ident packets
> will not break anything and depending on your border protection may be your
> only choice. It would be better (netiquette) to reject them if you have this
> capability.
>
> Dean A. Luethje, Sysadmin
> Bell Paper Box, Inc.
>
> ...Any opinions expressed are mine alone and do not reflect official company
> opinion or policy
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Luiz Eduardo Iadocicco
> Sent: Monday, July 17, 2000 12:33 PM
> To: [EMAIL PROTECTED]
> Subject: RES: Port 113 !
>
>
> Excuse me but somebody knows about the consequences of turning off this port
> ( port 113 ). I have a filter that not leaving this port to pass and I don�t
> get notice the consequences .
>
> thank you
>
> Luiz Eduardo
>
> -
> [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.]
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Cutting the space budget really restores my faith in humanity. It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
***testing, only testing, and damn good at it too!***
OK, so you're a Ph.D. Just don't touch anything.
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
