1. Forum
  2. Usenet
  3. COMP.OS.LINUX.SECURITY

  • portmap/rpcbind and tcpwrapper

    From William Unruh@21:1/5 to All on Thu Oct 1 07:48:18 2015
    XPost: alt.os.linux.mageia

    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rob van der Putten@21:1/5 to William Unruh on Sat Oct 10 15:32:14 2015
    XPost: alt.os.linux.mageia

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to Rob van der Putten on Sat Oct 10 15:58:37 2015
    XPost: alt.os.linux.mageia

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Pascal Hambourg@21:1/5 to All on Sat Oct 10 18:31:08 2015
    XPost: alt.os.linux.mageia

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to Pascal Hambourg on Sat Oct 10 20:11:43 2015
    XPost: alt.os.linux.mageia

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Pascal Hambourg@21:1/5 to All on Sun Oct 11 11:37:04 2015
    XPost: alt.os.linux.mageia

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rob van der Putten@21:1/5 to William Unruh on Mon Oct 12 09:54:56 2015
    XPost: alt.os.linux.mageia

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to Rob van der Putten on Mon Oct 12 17:09:56 2015
    XPost: alt.os.linux.mageia

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Pascal Hambourg@21:1/5 to All on Mon Oct 12 21:01:05 2015
    XPost: alt.os.linux.mageia

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rob van der Putten@21:1/5 to William Unruh on Mon Oct 12 21:39:25 2015
    XPost: alt.os.linux.mageia

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to Pascal Hambourg on Mon Oct 12 22:18:03 2015
    XPost: alt.os.linux.mageia

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From SyMcBean ( http://lampe2e.blogspot.@21:1/5 to William Unruh on Thu Oct 22 14:55:52 2015
    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).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to colin.mckinnon@gmail.com on Fri Oct 23 00:15:13 2015
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)