At 10:07 17-07-2000 -0300, you wrote:
Good morning!
Somebody knows so that it serves the port 113, my email server it tries to
connect the other servers in this port. Does anybody know because?
Port 113 is used for authentication.
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
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
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:
Ron DuFresne wrote Cc [EMAIL PROTECTED]:
Lisa,
Yer URL, here, returns a "cannot connect to remote host" message.
Haha, maybe you *think* a bit between From: and the given URL and
try http://cco.CISCO.COM/warp/customer/110/2.html
*giggle*
ciao
--
Philipp Buehler, aka fIpS | BOfH | NUCH |
Ben,
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.
I thought I had read somewhere that Linux sends an ICMP 3/3 (port
unreachable)... maybe other implementations do it
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
Hi all,
http://cco/warp/customer/110/2.html
This URL has the answers to the question.
Thanks much,
Lisa Napier
Product Security Incident Response Team
Cisco Systems
http://www.cisco.com/warp/public/707/sec_incident_response.shtml
PGP: A671 782D 2926 B489 F81A 3D5E B72F E407 B72C AF1F
ID:
Lisa,
Yer URL, here, returns a "cannot connect to remote host" message.
Thanks,
Ron DuFresne
On Mon, 13 Mar 2000, Lisa Napier wrote:
Hi all,
http://cco/warp/customer/110/2.html
This URL has the answers to the question.
Thanks much,
Lisa Napier
Product Security Incident
Groan... Apologies to all. I can only say it was a pre-coffee url copy.
Here's the real one:
http://www.cisco.com/warp/public/110/2.html
Many thanks for pointing out my error.
Lisa Napier
Product Security Incident Response Team
Cisco Systems
Lisa Napier writes:
http://cco/warp/customer/110/2.html
This URL has the answers to the question.
Ron DuFresne writes:
Yer URL, here, returns a "cannot connect to remote host" message.
Try http://cco.cisco.com/warp/public/110/2.html instead.
Jim
--
Jim Duncan, Product Security
-Original Message-
From: Lisa Napier [mailto:[EMAIL PROTECTED]mailto:[EMAIL PROTECTED]]
Sent: Monday, March 13, 2000 11:36 AM
To: Ron DuFresne; [EMAIL PROTECTED]
Cc: Pere Camps; [EMAIL PROTECTED]
Subject: Re: Port 113
Groan... Apologies to all. I can only say it was a
pre-coffee
behavior of
silently dropping connections?
YL
-Original Message-
From: Lisa Napier [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 13, 2000 11:36 AM
To: Ron DuFresne; [EMAIL PROTECTED]
Cc: Pere Camps; [EMAIL PROTECTED]
Subject: Re: Port 113
Groan... Apologies
, 2000 11:36 AM
To: Ron DuFresne; [EMAIL PROTECTED]
Cc: Pere Camps; [EMAIL PROTECTED]
Subject: Re: Port 113
Groan... Apologies to all. I can only say it was a
pre-coffee url copy.
Here's the real one:
http://www.cisco.com/warp/public/110/2.html
Many
PROTECTED]
Cc: Pere Camps; [EMAIL PROTECTED]
Subject: Re: Port 113
Groan... Apologies to all. I can only say it was a
pre-coffee url copy.
Here's the real one:
http://www.cisco.com/warp/public/110/2.html
Many thanks for pointing out my error.
Lisa Napier
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
Hello,
request and tries again before giving up. There was also mention of a way
to have the f/w do something other than silently drop the packet to allow
the server to give up more quickly.
Don't know how to set it up in pix, but what you have to do is to
REJECT the packets
A better solution would be for your firewall to
RESET, rather than DROP the connection. This way
the remote server tears down it's query, rather than
waiting for a timeout.
Okay, that sounds reasonable. However, this should be done for all IP
addresses, not just the hosts occupying IP
Can anyone explain to me if exist any attack using port 113/tcp
I had seen some packets Deny in my logs, incoming from
various IP address.
That being said, port 113 is useless and should be
blocked. .
~Patrick
-
In addition port 113 is used by the chat trojan "Kazimas". It´s
On Tue 1999-12-07 (16:15), Mullen, Patrick wrote:
That being said, port 113 is useless and should be blocked. Better
yet, don't even run the daemon at all.
read rfc1413 defining ident.
the daemon is for the profit of the one running it on a multiuser or
maybe routing system (think about NAT).
t Springer [EMAIL PROTECTED] on 08/12/99 00:35:26
Please respond to Helmut Springer [EMAIL PROTECTED]
To: firewalls list [EMAIL PROTECTED]
cc:(bcc: Helen Richardson/UK/IBM)
Subject: Re: port 113
On Tue 1999-12-07 (16:15), Mullen, Patrick wrote:
That being said, port 113 is useless
Our experience with port 113, the AUTH port, is that peak performance is
maintained with it allowed through the firewall. This does not mean the
AUTH service has to be running.
Let me explain.
If you block the AUTH port, the client requesting AUTH info from an inside
host will not receive any
Our experience with port 113, the AUTH port, is that peak
performance is
maintained with it allowed through the firewall. This does
not mean the
AUTH service has to be running.
A better solution would be for your firewall to
RESET, rather than DROP the connection. This way
the remote
"John" == John S Huggins [EMAIL PROTECTED] writes:
John Our experience with port 113, the AUTH port, is that peak performance is
John maintained with it allowed through the firewall. This does not mean the
John AUTH service has to be running.
The _best_ option is to have your firewall return
Thanks all. Now I have yet another trick in the big firewall bag.
John
On Wed, 8 Dec 1999, Mullen, Patrick wrote:
- Our experience with port 113, the AUTH port, is that peak
- performance is
- maintained with it allowed through the firewall. This does
- not mean the
- AUTH service has to
Our experience with port 113, the AUTH port, is that peak performance is
maintained with it allowed through the firewall. This does not mean the
an appropriate reject instead of silently dropping packets to 113 at the
firewall does the same. you don't want to let packets pass your
firewall
A better solution would be for your firewall to
RESET, rather than DROP the connection. This way
the remote server tears down it's query, rather than
waiting for a timeout.
Okay, that sounds reasonable. However, this should be done for all IP
addresses, not just the hosts occupying IP
Port 113 TCP and UDP is an Authentication Service
if that's what you wanted to know.
/Jimi
- Original Message -
From:
Edy - UOL
To: firewall-lista
Sent: Tuesday, December 07, 1999 01:52
PM
Subject: port 113
Hello all,Can anyone explain to me if exist any
attack
Can anyone explain to me if exist any attack using port 113/tcp
I had seen some packets Deny in my logs, incoming from
various IP address.
113 is the auth ("ident") port. People can use this
information to determine what user id daemons are
running as. The idea is that it's much
28 matches
Mail list logo
