Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.security > #660 > unrolled thread

portmap/rpcbind and tcpwrapper

Back to article view | Back to comp.os.linux.security

Contents

  portmap/rpcbind and tcpwrapper William Unruh <unruh@invalid.ca> - 2015-10-01 07:48 +0000
    Re: portmap/rpcbind and tcpwrapper Rob van der Putten <rob@sput.nl> - 2015-10-10 15:32 +0200
      Re: portmap/rpcbind and tcpwrapper William Unruh <unruh@invalid.ca> - 2015-10-10 15:58 +0000
        Re: portmap/rpcbind and tcpwrapper Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2015-10-10 18:31 +0200
          Re: portmap/rpcbind and tcpwrapper William Unruh <unruh@invalid.ca> - 2015-10-10 20:11 +0000
            Re: portmap/rpcbind and tcpwrapper Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2015-10-11 11:37 +0200
            Re: portmap/rpcbind and tcpwrapper Rob van der Putten <rob@sput.nl> - 2015-10-12 09:54 +0200
              Re: portmap/rpcbind and tcpwrapper William Unruh <unruh@invalid.ca> - 2015-10-12 17:09 +0000
                Re: portmap/rpcbind and tcpwrapper Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2015-10-12 21:01 +0200
                  Re: portmap/rpcbind and tcpwrapper William Unruh <unruh@invalid.ca> - 2015-10-12 22:18 +0000
                Re: portmap/rpcbind and tcpwrapper Rob van der Putten <rob@sput.nl> - 2015-10-12 21:39 +0200
    Re: portmap/rpcbind and tcpwrapper "SyMcBean ( http://lampe2e.blogspot.co.uk )" <colin.mckinnon@gmail.com> - 2015-10-22 14:55 -0700
      Re: portmap/rpcbind and tcpwrapper William Unruh <unruh@invalid.ca> - 2015-10-23 00:15 +0000

#660 — portmap/rpcbind and tcpwrapper

portmap/rpcbind is supposed to controllabl by tcpwrapper. I have a line
rpcbind portmap: ALL:deny

in /etc/hosts.allow after a line
rpcbind portmap: 192.168.0.0/24 : allow

But then I can still run rpcinfo on a machine from outside that network
and et responses.
Does rpcbind respect tcpwrapper or not?

[toc] | [next] | [standalone]

#661

Hi there


William Unruh wrote:

> portmap/rpcbind is supposed to controllabl by tcpwrapper. I have a line
> rpcbind portmap: ALL:deny

Try;
portmap: ALL: deny

> in /etc/hosts.allow after a line
> rpcbind portmap: 192.168.0.0/24 : allow

Try;
portmap: 192.168.0.0/24 : allow

> But then I can still run rpcinfo on a machine from outside that network
> and et responses.
> Does rpcbind respect tcpwrapper or not?

Yes.


Regards,
Rob
-- 
ISDS is evil. Abolish ISDS.

[toc] | [prev] | [next] | [standalone]

#662

On 2015-10-10, Rob van der Putten <rob@sput.nl> wrote:
> Hi there
>
>
> William Unruh wrote:
>
>> portmap/rpcbind is supposed to controllabl by tcpwrapper. I have a line
>> rpcbind portmap: ALL:deny
>
> Try;
> portmap: ALL: deny

Nope. rpcbind has tcpwrappers disables by default, and Mageia (and I
suspect many other distros) just accepts the default. 

>
>> in /etc/hosts.allow after a line
>> rpcbind portmap: 192.168.0.0/24 : allow
>
> Try;
> portmap: 192.168.0.0/24 : allow

??? tcpwrappers accepts the  a b c d: addr1 addr2 : 
form in /etc/hosts.allow. 

>
>> But then I can still run rpcinfo on a machine from outside that network
>> and et responses.
>> Does rpcbind respect tcpwrapper or not?
>
> Yes.

No it does not. I looked at the source, and in configure is
  --enable-libwrap        Enables host name checking through tcpd [default=no]

  Note the default. This is something that has happened secretly in the
  past two years. 

  The problem is that my one machine is "known" to have an open rpcinfo,
  and thus it keeps getting hammered by this stupic rpc amplification
  attack, even after I have enabled tcpwrapppers ( and it works as the
  logs say) Since the udp packets response is being misdirected there is
  no way the attacker knows that his amplification is not working so it
  keeps on going. 10000 attempts per day filling my tcpwrapper logs. 



>
>
> Regards,
> Rob

[toc] | [prev] | [next] | [standalone]

#663

William Unruh a écrit :
> 
>   The problem is that my one machine is "known" to have an open rpcinfo,
>   and thus it keeps getting hammered by this stupic rpc amplification
>   attack, even after I have enabled tcpwrapppers ( and it works as the
>   logs say) Since the udp packets response is being misdirected there is
>   no way the attacker knows that his amplification is not working so it
>   keeps on going. 10000 attempts per day filling my tcpwrapper logs. 

You may consider to :
- specify the address(es) rpcbind listens on with -h ;
- filter undesirable RPC requests with iptables.

[toc] | [prev] | [next] | [standalone]

#664

On 2015-10-10, Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
> William Unruh a ?crit :
>> 
>>   The problem is that my one machine is "known" to have an open rpcinfo,
>>   and thus it keeps getting hammered by this stupic rpc amplification
>>   attack, even after I have enabled tcpwrapppers ( and it works as the
>>   logs say) Since the udp packets response is being misdirected there is
>>   no way the attacker knows that his amplification is not working so it
>>   keeps on going. 10000 attempts per day filling my tcpwrapper logs. 
>
> You may consider to :
> - specify the address(es) rpcbind listens on with -h ;
> - filter undesirable RPC requests with iptables.

rpcbind does not honour libwrap by default. 

[toc] | [prev] | [next] | [standalone]

#665

William Unruh a écrit :
> On 2015-10-10, Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
>>
>> You may consider to :
>> - specify the address(es) rpcbind listens on with -h ;
>> - filter undesirable RPC requests with iptables.
> 
> rpcbind does not honour libwrap by default. 

My two suggestions have nothing to do with libwrap support.

[toc] | [prev] | [next] | [standalone]

#666

Hi there


William Unruh wrote:

> rpcbind does not honour libwrap by default.

Over here it does (libwrap);

sput:~$ which rpcbind
/sbin/rpcbind
sput:~$ ldd /sbin/rpcbind
  linux-gate.so.1 =>  (0xb76f5000)
  libwrap.so.0 => /lib/i386-linux-gnu/libwrap.so.0 (0xb76dd000)
  libtirpc.so.1 => /lib/i386-linux-gnu/libtirpc.so.1 (0xb76b6000)
  libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 
(0xb769c000)
  libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb7538000)
  libnsl.so.1 => /lib/i386-linux-gnu/i686/cmov/libnsl.so.1 (0xb7521000)
  libgssglue.so.1 => /lib/i386-linux-gnu/libgssglue.so.1 (0xb7516000)
  libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xb7512000)
  /lib/ld-linux.so.2 (0xb76f6000)


Regards,
Rob
-- 
ISDS is evil. Abolish ISDS.

[toc] | [prev] | [next] | [standalone]

#667

On 2015-10-12, Rob van der Putten <rob@sput.nl> wrote:
> Hi there
>
>
> William Unruh wrote:
>
>> rpcbind does not honour libwrap by default.
>
> Over here it does (libwrap);

Which version? Which distribution?

As I said it does not honour libwrap by default. You can compile it to
honour libwarp (--enable-libwrap in configure). And the default just
changed about 2 years ago. 

>
> sput:~$ which rpcbind
> /sbin/rpcbind
> sput:~$ ldd /sbin/rpcbind
>   linux-gate.so.1 =>  (0xb76f5000)
>   libwrap.so.0 => /lib/i386-linux-gnu/libwrap.so.0 (0xb76dd000)
>   libtirpc.so.1 => /lib/i386-linux-gnu/libtirpc.so.1 (0xb76b6000)
>   libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 
> (0xb769c000)
>   libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb7538000)
>   libnsl.so.1 => /lib/i386-linux-gnu/i686/cmov/libnsl.so.1 (0xb7521000)
>   libgssglue.so.1 => /lib/i386-linux-gnu/libgssglue.so.1 (0xb7516000)
>   libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xb7512000)
>   /lib/ld-linux.so.2 (0xb76f6000)
>
>
> Regards,
> Rob

[toc] | [prev] | [next] | [standalone]

#668

William Unruh a écrit :
> On 2015-10-12, Rob van der Putten <rob@sput.nl> wrote:
>>
>> William Unruh wrote:
>>
>>> rpcbind does not honour libwrap by default.
>> Over here it does (libwrap);
> 
> Which version? Which distribution?

The mention of "Iceape" in the message headers suggests the distribution
is Debian or a derivative. Iceape is the unbranded version of Seamonkey
provided by Debian.

Indeed rpcbind depends on libwrap0 in all currently maintained versions
of Debian.

[toc] | [prev] | [next] | [standalone]

#670

On 2015-10-12, Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
> William Unruh a ?crit :
>> On 2015-10-12, Rob van der Putten <rob@sput.nl> wrote:
>>>
>>> William Unruh wrote:
>>>
>>>> rpcbind does not honour libwrap by default.
>>> Over here it does (libwrap);
>> 
>> Which version? Which distribution?
>
> The mention of "Iceape" in the message headers suggests the distribution
> is Debian or a derivative. Iceape is the unbranded version of Seamonkey
> provided by Debian.
>
> Indeed rpcbind depends on libwrap0 in all currently maintained versions
> of Debian.

Good. By default, rpcbind does not. Ie, you have explicitly put in 
--enable-libwrap as an argument to the configure script in order to have
rpcbind use libwrap. And may distros do not do so. 
When asked they get all holy, and say that libwrap is not a good thing,
and people should use a firewall instead. So silently breaking a working
security fence is OK, because there are situtions in which that fence
has weaknesses. 

[toc] | [prev] | [next] | [standalone]

#669

Hi there


William Unruh wrote:

> Which version? Which distribution?

Debian

> As I said it does not honour libwrap by default. You can compile it to
> honour libwarp (--enable-libwrap in configure). And the default just
> changed about 2 years ago.

Can it be run from (x)inetd?


Regards,
Rob
-- 
ISDS is evil. Abolish ISDS.

[toc] | [prev] | [next] | [standalone]

#671

On Thursday, October 1, 2015 at 8:50:21 AM UTC+1, William Unruh wrote:
> Does rpcbind respect tcpwrapper or not?

Running the binary through ldd will tell you what it was linked against:

kermit:/sbin # ldd rpcbind
        linux-vdso.so.1 (0x00007fffcb1a1000)
        libtirpc.so.1 => /lib64/libtirpc.so.1 (0x00007fb123ce4000)
        libsystemd-daemon.so.0 => /usr/lib64/libsystemd-daemon.so.0 (0x00007fb123ae0000)
        libsystemd-journal.so.0 => /usr/lib64/libsystemd-journal.so.0 (0x00007fb1238c4000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb1236a6000)
        libwrap.so.0 => /lib64/libwrap.so.0 (0x00007fb12349b000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fb1230ed000)
        libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00007fb122ea7000)
        librt.so.1 => /lib64/librt.so.1 (0x00007fb122c9f000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fb122a7b000)
        liblzma.so.5 => /usr/lib64/liblzma.so.5 (0x00007fb122855000)
        libgcrypt.so.11 => /usr/lib64/libgcrypt.so.11 (0x00007fb1225d5000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fb123f0d000)
        libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00007fb122306000)
        libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00007fb1220d3000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fb121ecf000)
        libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00007fb121cc2000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fb121abe000)
        libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007fb121858000)
        libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 (0x00007fb121653000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fb12144f000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fb121238000)

(linked to libwrap here).

[toc] | [prev] | [next] | [standalone]

#672

On 2015-10-22, SyMcBean ( http://lampe2e.blogspot.co.uk ) <colin.mckinnon@gmail.com> wrote:
> On Thursday, October 1, 2015 at 8:50:21 AM UTC+1, William Unruh wrote:
>> Does rpcbind respect tcpwrapper or not?
>
> Running the binary through ldd will tell you what it was linked against:
>
> kermit:/sbin # ldd rpcbind
...
>         libwrap.so.0 => /lib64/libwrap.so.0 (0x00007fb12349b000)
..
> (linked to libwrap here).

But by default no. And some distros use the default. 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.security

csiph-web