RE: TCP delay, solved

RE: TCP delay, solved

[Nathan Cassano]

Well you learn something new every day. Today I learned inetd does ident
checks on it's clients. This is annoying, is there a way you can turn
this off inside inetd?

So I added a rule to return the port-unreachable error and everything
now works hunky dory. Thanks everyone for your help.

iptables -A INPUT -p tcp --dport 113 -j REJECT --reject-with tcp-reset

-----Original Message-----
From: Evan Cofsky [mailto:unix@theunixman.com] 
Sent: Wednesday, June 12, 2002 8:46 AM
To: Nathan Cassano
Cc: netfilter@lists.samba.org
Subject: Re: TCP delay


It really sounds like ident lookups.  Telnet is typically started by
tcpwrappers (tcpd), and Sendmail (I don't know about other MTAs)
typically does ident lookups.  If you're not running the identd, or
having it start through inetd, but are still DROPping inbound packets
to the SMTP client machine, the SMTP server will never receive the
normal "connection refused" messages from the kernel, but will have to
wait for it to time out.

Re: TCP delay, solved

[Antony Stone]

On Wednesday 12 June 2002 5:33 pm, Nathan Cassano wrote:

> Well you learn something new every day. Today I learned inetd does ident
> checks on it's clients.

Yes, it's called tcpwrappers, and has been pretty standard on systems for I'd 
say about four years now :-)

> This is annoying, is there a way you can turn
> this off inside inetd?

Yes, it's the bit on each line of /etc/inetd.conf which says "/usr/sbin/tcpd" 
- it does an ident lookup and logs the access to syslog before handing the 
connection over to the real daemon.

If you don't want this to happen them remove the "/usr/sbin/tcpd" from 
inetd.conf and just have the standard daemon listed there on its own.

 

Antony.

Re: TCP delay, solved

[Juri Haberland]

Antony Stone <Antony@soft-solutions.co.uk> wrote:
> On Wednesday 12 June 2002 5:33 pm, Nathan Cassano wrote:
> 
>> Well you learn something new every day. Today I learned inetd does ident
>> checks on it's clients.
> 
> Yes, it's called tcpwrappers, and has been pretty standard on systems for I'd 
> say about four years now :-)

That might not be true. Actually it depends on how the tcpwrappers are
compiled. AFAIK the tcpwrappers are compiled with ident lookup by
default but these are only done when you have a line like:

in.ftpd: user@192.168.0.

in your hosts.access file. So in general the tcpwrappers do not do ident
lookups.

>> This is annoying, is there a way you can turn
>> this off inside inetd?
> 
> Yes, it's the bit on each line of /etc/inetd.conf which says "/usr/sbin/tcpd" 
> - it does an ident lookup and logs the access to syslog before handing the 
> connection over to the real daemon.
> 
> If you don't want this to happen them remove the "/usr/sbin/tcpd" from 
> inetd.conf and just have the standard daemon listed there on its own.

This is a very bad advice as the tcpwrappers are a standard security
tool which shouldn't be disabled!
And it won't help in cases of telnet and ftp as they do their ident lookups
themselfs!

The only way to go is to use iptables to reject those lookups.

Cheers,
Juri

-- 
Juri Haberland  <juri@koschikode.com> 

Re: TCP delay, solved

[Antony Stone]

On Thursday 13 June 2002 10:59 am, Juri Haberland wrote:

> >> This is annoying, is there a way you can turn
> >> this off inside inetd?
> >
> > Yes, it's the bit on each line of /etc/inetd.conf which says
> > "/usr/sbin/tcpd" - it does an ident lookup and logs the access to syslog
> > before handing the connection over to the real daemon.
> >
> > If you don't want this to happen them remove the "/usr/sbin/tcpd" from
> > inetd.conf and just have the standard daemon listed there on its own.
>
> This is a very bad advice as the tcpwrappers are a standard security
> tool which shouldn't be disabled!

I wasn't advocating this as good advice - I was simply answering the question 
"how do I do it".

I don't regard eliminating tcpwrappers as a good idea, just for the record.

Mind you, I do also think that ident lookups are a bit of an anachronism 
which we could well do without in many situations these days, however I don't 
like having a firewall which automatically responds on port 113 to anyone who 
cares to probe it...

There's no satisfactory answer to this problem at present, I think.

 

Antony.

RE: TCP delay, solved

[David Luyer]

[ ident lookups causing tcpd to be slow ]

> There's no satisfactory answer to this problem at present, I think.

umm, reading the manual?

man 5 hosts_access [on Debian Linux at least]

CLIENT USERNAME LOOKUP
       When  the client host supports the RFC 931 protocol or one
       of its descendants (TAP, IDENT, RFC 1413) the wrapper pro--
       grams  can retrieve additional information about the owner
       of a connection. Client username information, when  avail--
       able,  is  logged  together with the client host name, and
       can be used to match patterns like:

          daemon_list : ... user_pattern@host_pattern ...

       The daemon wrappers can be configured at compile  time  to
       perform  rule-driven  username  lookups  (default)  or  to
       always interrogate the client host.  In the case of  rule-
       driven  username lookups, the above rule would cause user--
       name  lookup  only  when  both  the  daemon_list  and  the
       host_pattern match.

So it's a compile option on tcpd.  Recompile with it disabled.

David.

Re: TCP delay, solved

[Antony Stone]

On Friday 14 June 2002 8:15 am, David Luyer wrote:

> [ ident lookups causing tcpd to be slow ]
>
> > There's no satisfactory answer to this problem at present, I think.
>
> So it's a compile option on tcpd.  Recompile with it disabled.

Yes, but that would need to be done by everyone out on the Internet whose 
systems my clients try to contact, otherwise we're still going to get those 
long delays (or a hole in my firewall).

Not what I consider a "satisfactory solution" :-)

 

Antony.

RE: TCP delay, solved

[David Luyer]

> On Friday 14 June 2002 8:15 am, David Luyer wrote:
> 
> > [ ident lookups causing tcpd to be slow ]
> >
> > > There's no satisfactory answer to this problem at 
> > > present, I think.
> >
> > So it's a compile option on tcpd.  Recompile with it disabled.
> 
> Yes, but that would need to be done by everyone out on the 
> Internet whose systems my clients try to contact, otherwise
> we're still going to get those long delays (or a hole in my
> firewall).
> 
> Not what I consider a "satisfactory solution" :-)

Ah.  I missed the start of the discussion.  You're blocking ident
lookups on your customers, and it's causing them to have problems
accessing some sites and services?

Easy solution:

  deny (connection reset) rather than drop the connections

Hard solution:

  transproxy ident and return a cryptographic hash representing
  the actual client online on the IP which the ident request is
  for (this is a much cooler solution but I only know one ISP to
  have done it)

David.

RE: TCP delay, solved

[David Luyer]

> Easy solution:
> 
>   deny (connection reset) rather than drop the connections

I meant reject.  From the man page:

   REJECT
       This  is  used to send back an error packet in response to
       the matched packet: otherwise it is equivalent to DROP  so
       it  is  a terminating TARGET, ending rule traversal.  This
       target is only valid in  the  INPUT,  FORWARD  and  OUTPUT
       chains, and user-defined chains which are only called from
       those chains.  The following option controls the nature of
       the error packet returned:

       --reject-with type
              The  type  given can be icmp-net-unreachable, icmp-
              host-unreachable,   icmp-port-unreachable,    icmp-
              proto-unreachable,   icmp-net-prohibited  or  icmp-
              host-prohibited, which return the appropriate  ICMP
              error  message  (port-unreachable  is the default).
              The option tcp-reset can be  used  on  rules  which
              only  match the TCP protocol: this causes a TCP RST
              packet to be sent back.  This is mainly useful  for
              blocking  ident  (113/tcp)  probes which frequently
              occur when sending mail to broken mail hosts (which
              won't accept your mail otherwise).

Why connection reset?  For idiots at the other end who firewall all
ICMP.

David.

Re: TCP delay, solved

[Antony Stone]

On Friday 14 June 2002 9:17 am, David Luyer wrote:

> Ah.  I missed the start of the discussion.  You're blocking ident
> lookups on your customers, and it's causing them to have problems
> accessing some sites and services?
>
> Easy solution:
>
>   deny (connection reset) rather than drop the connections

Yes, that's the "hole in my firewall" I referred to.   By sending back RST to 
packets coming in on TCP port 113, I'm telling people there's a firewall 
there.   All other ports send back nothing, and I don't want this one to 
stand out as being different....

> Hard solution:
>
>   transproxy ident

Explain please ?

>   and return a cryptographic hash representing
>   the actual client online on the IP which the ident request is
>   for

Sounds more than most situations would need.   Why bother to send back 
something actually related to the user (yes, I know this is what Ident's 
expecting, but it's not necessary) ?   So long as Ident responds with 
*something* (such as 'no-user') then the remote server will be happy and talk 
to you without a timeout.

The problem is making sure this only happens in response to an outgoing 
packet (ie the Ident request gets treated as RELATED to the initial 
connection), rather than providing an Ident daemon which answers any request 
which comes in (eg port scan).

 

Antony.

Re: TCP delay, solved

[Antony Stone]

On Friday 14 June 2002 9:25 am, David Luyer wrote:

> > Easy solution:
> >
> >   deny (connection reset) rather than drop the connections
>
> I meant reject.  From the man page:
>
> Why connection reset?  For idiots at the other end who firewall all
> ICMP.

Same problem.   Leaves me with a port on my Firewall which responds to nmap 
etc.   All other ports on my Firewall return nothing, so the machine is 
invisible - I don't want port 113 standing out by doing something different.

 

Antony.

Re: TCP delay, solved

[Tony Earnshaw]

[-- Attachment #1: Type: text/plain, Size: 671 bytes --]

fre, 2002-06-14 kl. 11:16 skrev Antony Stone:

> Yes, that's the "hole in my firewall" I referred to.   By sending back RST to 
> packets coming in on TCP port 113, I'm telling people there's a firewall 
> there.   All other ports send back nothing, and I don't want this one to 
> stand out as being different....

They know anyway.

216.167.114.177

Best,

Tony

-- 

Tony Earnshaw

e-post:		tonni@billy.demon.nl
www:		http://www.billy.demon.nl
gpg public key:	http://www.billy.demon.nl/tonni.armor

Telefoon:	(+31) (0)172 530428
Mobiel:		(+31) (0)6 51153356

GPG Fingerprint = 3924 6BF8 A755 DE1A 4AD6 FA2B F7D7 6051 3BE7 B981
3BE7B981



[-- Attachment #2: Dette er en digitalt signert meldingsdel --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: TCP delay, solved

[Joe Patterson]

How about this as a possible solution:

in your OUTPUT chain and in FORWARD -o $EXTERNAL_INT, have a rule something
like (with the recent patch compiled in):

$IPT -A OUTPUT -m state --state NEW -m recent --name validconn --set
$IPT -A FORWARD -m state --state NEW -o $EXTERNAL_INT -m recent --name
validconn --set

and then:

$IPT -A INPUT -m recent --name validconn -rcheck --seconds 20 -p tcp --dport
113 -j REJECT --reject-with tcp-reset

and let everything else fall through to a default DROP rule.  This way you
will only send tcp resets for ident lookups if you have made a connection to
the source of the ident lookup in the last 20 seconds.  Otherwise (for
general nmappers out there), everything gets dropped.  Add this to some -m
psd magic and some other judicious use of the recent patch, and you should
be able to have a firewall that denies all evidence that you exist.

-Joe

> -----Original Message-----
> From: netfilter-admin@lists.samba.org
> [mailto:netfilter-admin@lists.samba.org]On Behalf Of Antony Stone
> Sent: Friday, June 14, 2002 5:19 AM
> To: netfilter@lists.samba.org
> Subject: Re: TCP delay, solved
>
>
> On Friday 14 June 2002 9:25 am, David Luyer wrote:
>
> > > Easy solution:
> > >
> > >   deny (connection reset) rather than drop the connections
> >
> > I meant reject.  From the man page:
> >
> > Why connection reset?  For idiots at the other end who firewall all
> > ICMP.
>
> Same problem.   Leaves me with a port on my Firewall which
> responds to nmap
> etc.   All other ports on my Firewall return nothing, so the machine is
> invisible - I don't want port 113 standing out by doing something
> different.
>
>
>
> Antony.
>
>
>

RE: TCP delay, solved

[Joe Patterson]

OOPS.  Treat this message as further proof that crack don't smoke itself...
The rules here would *NOT* work.  However, I think there's a gleam of
possibility here...  Not quite as good as I had thought, but still a
reasonable thing to do:

$IPT -A INPUT -p tcp --tcp-flags ALL SYN,ACK -m state --state ESTABLISHED -m
recent --name validconn --set
$IPT -A FORWARD -p tcp --tcp-flags ALL SYN,ACK -m state --state
ESTABLISHED -i $EXTERNAL_INT -m recent --name validconn --set
$IPT -A INPUT -m recent --name validconn -rcheck --seconds 20 -p tcp --dport
113 -j REJECT --reject-with tcp-reset

This is based on assumptions which may or may not be correct.  First, the
timeline of a normal connection from an inside client to an outside server
that does ident lookups:

1:client sends SYN, firewall sees this as state NEW.
2:server inetd (or whatever) replies with SYN-ACK, firewall sees this as
state ESTABLISHED, and adds the server's IP to the validconn group.
3:client replies with an ACK, firewall sees this as ESTABLISHED
4:server's inetd fork's and exec's tcpd, which immediately gets the info on
the socket it's been handed, and creates an ident SYN, which it sends to the
client.
5:Firewall recieves the ident SYN, checks the validconn group, sees that the
server is in it, and replies with a RST.
6:tcpd gives up on ident, and exec's the server that should handle whatever
port is being connected to.
7:traffic flows as normal.

This will fail if tcpd (or a program with libwrap, or anything that does
ident lookups) tries to do an ident lookup before the tcp 3-way handshake is
over... but I don't think it does.  I think it waits until the connection is
established.

This will also fail for ident lookups of udp based stuff, but I'm fairly
sure that identd for udp based services is in violation of the relevant
rfc's (931, I believe)

Now, from the attacker's standpoint:

1: if the attacker sends something to 113, it will be dropped because their
source is not in the validconn group
2: if the attacker sends an unsolicited SYN-ACK, it will be in state NEW, so
will be dropped and not add the attacker to the validconn group.
3: if the attacker sends a SYN to an open port that is allowed by the FW,
and gets a SYN-ACK back, that hasn't triggered any of the above rules, so he
still won't be able to send ident lookups (although at this point he already
knows that you're there, so it doesn't *really* matter)
4: after making a connection to an open allowed port, he could send a
SYN-ACK, which would be an invalid tcp packet at that point but I don't
think it would be "-m state --state INVALID", at which point he would have
free license to send all the ident requests that he desires for the next 20
seconds.
5: the really sneaky one:  If he connects to a port on the firewall that's
doing its own ident lookups, then the ident lookup itself (from the
firewall, or whatever the firewall is passing traffic to) will trigger the
above rules, thus allowing the attacker to have free license to send ident
requests for the next 20 seconds.

So, it's not perfect.  There is some slippage.  But, I do think it's kind of
elegant, and I think it should work fairly well.  Especially on a firewall
that's only allowing outbound connections, it should be fairly solid and
usefull.  I'll have to try it on a real live firewall sometime soon....

-Joe

> -----Original Message-----
> From: netfilter-admin@lists.samba.org
> [mailto:netfilter-admin@lists.samba.org]On Behalf Of Joe Patterson
> Sent: Friday, June 14, 2002 4:30 PM
> To: Antony Stone; netfilter@lists.samba.org
> Subject: RE: TCP delay, solved
>
>
> How about this as a possible solution:
>
> in your OUTPUT chain and in FORWARD -o $EXTERNAL_INT, have a rule
> something
> like (with the recent patch compiled in):
>
> $IPT -A OUTPUT -m state --state NEW -m recent --name validconn --set
> $IPT -A FORWARD -m state --state NEW -o $EXTERNAL_INT -m recent --name
> validconn --set
>
> and then:
>
> $IPT -A INPUT -m recent --name validconn -rcheck --seconds 20 -p
> tcp --dport
> 113 -j REJECT --reject-with tcp-reset
>
> and let everything else fall through to a default DROP rule.  This way you
> will only send tcp resets for ident lookups if you have made a
> connection to
> the source of the ident lookup in the last 20 seconds.  Otherwise (for
> general nmappers out there), everything gets dropped.  Add this to some -m
> psd magic and some other judicious use of the recent patch, and you should
> be able to have a firewall that denies all evidence that you exist.
>
> -Joe
>
> > -----Original Message-----
> > From: netfilter-admin@lists.samba.org
> > [mailto:netfilter-admin@lists.samba.org]On Behalf Of Antony Stone
> > Sent: Friday, June 14, 2002 5:19 AM
> > To: netfilter@lists.samba.org
> > Subject: Re: TCP delay, solved
> >
> >
> > On Friday 14 June 2002 9:25 am, David Luyer wrote:
> >
> > > > Easy solution:
> > > >
> > > >   deny (connection reset) rather than drop the connections
> > >
> > > I meant reject.  From the man page:
> > >
> > > Why connection reset?  For idiots at the other end who firewall all
> > > ICMP.
> >
> > Same problem.   Leaves me with a port on my Firewall which
> > responds to nmap
> > etc.   All other ports on my Firewall return nothing, so the machine is
> > invisible - I don't want port 113 standing out by doing something
> > different.
> >
> >
> >
> > Antony.
> >
> >
> >
>
>
>
>