hosts.allow does not resolve names - Networking

This is a discussion on hosts.allow does not resolve names - Networking ; hosts.allow does not work with network names. Would some kind soul tell me why it does not work? /etc/hosts.allow fails with ALL: .home.invalid but ALL: 192.168.1.0/255.255.255.0 works. $ hostname --domain home.invalid $ grep hosts: /etc/nsswitch.conf hosts: files dns $ cat ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: hosts.allow does not resolve names

  1. hosts.allow does not resolve names

    hosts.allow does not work with network names.
    Would some kind soul tell me why it does not work?

    /etc/hosts.allow fails with
    ALL: .home.invalid
    but ALL: 192.168.1.0/255.255.255.0 works.


    $ hostname --domain
    home.invalid

    $ grep hosts: /etc/nsswitch.conf
    hosts: files dns

    $ cat /etc/host.conf
    order hosts,bind
    multi on
    nospoof on
    spoofalert on

    $ head -4 /etc/hosts
    127.0.0.1 localhost
    192.168.1.213 m2008.home.invalid m2008
    192.168.1.11 fw.home.invalid fw
    192.168.1.130 wb.home.invalid wb

    Running Mandriva Linux release 2008.0

    Not running named/bind, NIS, YP. avahi*, tmdns

    Tried tcpdchk but Mandirva runs xinetd instead of inetd so it fails.

  2. Re: hosts.allow does not resolve names

    On Tue, 27 Nov 2007 07:13:05 GMT, Bit Twister wrote:
    > hosts.allow does not work with network names.
    > Would some kind soul tell me why it does not work?
    >
    > /etc/hosts.allow fails with
    > ALL: .home.invalid
    > but ALL: 192.168.1.0/255.255.255.0 works.


    Sorry, forgot the error messages.

    From /var/log/messages I would get
    Nov 26 18:56:24 m2008 portmap[5640]: connect from 192.168.1.130 \
    to getport(nfs): request from unauthorized host

    when using ALL: .home.invalid
    I would get the NFS mount with ALL: 192.168.1.0/255.255.255.0



    Hosts.deny mails me this message

    TCP Wrappers: Connection Refused
    By: m2008.home.invalid
    Process: portmap (pid 3676)

    User: unknown
    Host: 192.168.1.130
    Date: Mon Nov 26 18:56:23 CST 2007


  3. Re: hosts.allow does not resolve names

    On Tue, 27 Nov 2007, in the Usenet newsgroup comp.os.linux.networking, in
    article , Bit Twister wrote:

    >hosts.allow does not work with network names.


    OPINION: I don't like to use hostnames, as they are subject to spoofing.
    IP addresses are harder to spoof. Yes, in this case, it shouldn't be
    a major concern, but I go for blanket solutions.

    >Would some kind soul tell me why it does not work?
    >
    >/etc/hosts.allow fails with
    > ALL: .home.invalid
    >but ALL: 192.168.1.0/255.255.255.0 works.


    OK - syntax looks correct. No errant space or anything?

    > hostname --domain
    >home.invalid
    >
    >$ grep hosts: /etc/nsswitch.conf
    >hosts: files dns
    >
    >$ cat /etc/host.conf
    >order hosts,bind
    >multi on
    >nospoof on
    >spoofalert on


    If you drop the last two, does it work?

    >$ head -4 /etc/hosts


    OK. Assumption is no other lines containing those IP addresses.

    >Not running named/bind, NIS, YP. avahi*, tmdns


    If you do a 'strings | grep host /path/to/tcpd' you will see that it's
    using a standard 'gethostbyaddr' and 'gethostbyname' library calls, so
    if you can 'ping -c 1 m2008.home.invalid' then tcpd _should_ work. You
    may want to up the log level, because this same 'strings' command shows

    can't verify hostname: gethostbyname(%s) failed

    as one of the error messages. In your followup, you show tcpd logging
    the full name, so I _believe_ it is resolving the name (otherwise, it
    would be logging the IP), or am I mis-interpreting your mail snip?

    >Tried tcpdchk but Mandirva runs xinetd instead of inetd so it fails.


    That's a problem. Wietse Venema hasn't been maintaining the application
    for many years (7.6 is from March 1997), while xinetd was introduced in
    late 2000. You might try an 'strace' of xinitd but that sounds kind of
    messy.

    Old guy

  4. Re: hosts.allow does not resolve names

    On Tue, 27 Nov 2007 13:26:08 -0600, Moe Trin wrote:
    > article , Bit Twister wrote:
    >
    > OPINION: I don't like to use hostnames, as they are subject to spoofing.
    > IP addresses are harder to spoof. Yes, in this case, it shouldn't be
    > a major concern, but I go for blanket solutions.


    I hear where you are comming from. Was just trying to keep maintenance
    down while changing LAN ip values. Last resort is to script the LAN ip change.

    >>/etc/hosts.allow fails with
    >> ALL: .home.invalid
    >>but ALL: 192.168.1.0/255.255.255.0 works.

    >
    > OK - syntax looks correct. No errant space or anything?


    Nope, latest test
    ALL: 192.168.1.
    works,

    ALL: .home.invalid
    fails. So does ALL: wb.home.invalid, m2008.home.invalid


    >>$ cat /etc/host.conf
    >>order hosts,bind
    >>multi on
    >>nospoof on
    >>spoofalert on

    >
    > If you drop the last two, does it work?


    No, and changing last two to off did not work either.


    >>$ head -4 /etc/hosts

    >
    > OK. Assumption is no other lines containing those IP addresses.


    No,
    $ grep 213 /etc/hosts
    192.168.1.213 m2008.home.invalid m2008

    $ grep m2008 /etc/hosts
    192.168.1.213 m2008.home.invalid m2008


    > If you do a 'strings | grep host /path/to/tcpd' you will see that it's
    > using a standard 'gethostbyaddr' and 'gethostbyname' library calls, so
    > if you can 'ping -c 1 m2008.home.invalid' then tcpd _should_ work.


    Dang it, pings work, but NFS mount still fails with ALL: .home.invalid
    Nov 27 13:57:33 m2008 portmap[4702]: connect from 192.168.1.130 \
    to getport(nfs): request from unauthorized host

    $ cat /etc/exports
    /local wb(rw,no_root_squash,sync)

    $ ping -c 1 wb
    PING wb.home.invalid (192.168.1.130) 56(84) bytes of data.
    64 bytes from wb.home.invalid (192.168.1.130): icmp_seq=1 ttl=64 time=0.185 ms

    --- wb.home.invalid ping statistics ---
    1 packets transmitted, 1 received, 0% packet loss, time 0ms
    rtt min/avg/max/mdev = 0.185/0.185/0.185/0.000 ms


    > as one of the error messages. In your followup, you show tcpd logging
    > the full name, so I _believe_ it is resolving the name (otherwise, it
    > would be logging the IP), or am I mis-interpreting your mail snip?


    It would be misleading

    $ cat /etc/hosts.deny

    ALL: ALL:\
    spawn ( \
    /bin/echo -e "\n\
    TCP Wrappers\: Connection Refused\n\
    By\: $(uname -n)\n\
    Process\: %d (pid %p)\n\
    \n\
    User\: %u\n\
    Host\: %c\n\
    Date\: $(date)\n\
    " | /bin/mail -s \"$(uname -n)\" root ) & : DENY

    #****************** end hosts.deny ************


    but system is resolving correctly

    $ ping -c 1 $(uname -n)
    PING m2008.home.invalid (192.168.1.213) 56(84) bytes of data.
    64 bytes from m2008.home.invalid (192.168.1.213) icmp_seq=1 ttl=64 time=0.075 ms

    --- m2008.home.invalid ping statistics ---
    1 packets transmitted, 1 received, 0% packet loss, time 0ms
    rtt min/avg/max/mdev = 0.075/0.075/0.075/0.000 ms


    > That's a problem. Wietse Venema hasn't been maintaining the application
    > for many years (7.6 is from March 1997), while xinetd was introduced in
    > late 2000. You might try an 'strace' of xinitd but that sounds kind of
    > messy.


    Yes, that would be a bit of tracing since I am trying to make an NFS
    mount from wb.home.invalid

    Open/no firewalls on both systems makes no difference.


    Thank you for your time.

  5. Re: hosts.allow does not resolve names

    On Nov 26, 11:13 pm, Bit Twister wrote:
    > hosts.allow does not work with network names.
    > Would some kind soul tell me why it does not work?


    How would it know the host name? How do you imagine it works?

    DS

  6. Re: hosts.allow does not resolve names

    On Tue, 27 Nov 2007 16:46:31 -0800 (PST), David Schwartz wrote:
    >
    > How would it know the host name?


    It would look up the name in /etc/hosts

    > How do you imagine it works?


    I imagined it would work like man hosts.allow indicates

    The access control language implements the following patterns:

    · A string that begins with a ‘.´ character. A host name is
    matched if the last components of its name match the specified
    pattern. For example, the pattern ‘.tue.nl´ matches the host
    name ‘wzv.win.tue.nl´.

    then looking through man -s 5 hosts_access the example

    /etc/hosts.allow:
    ALL: LOCAL @some_netgroup
    ALL: .foobar.edu EXCEPT terminalserver.foobar.edu


    would suggest it should work. :-D

    Feel free to look through the rest of the thread for more info.

  7. Re: hosts.allow does not resolve names

    On Tue, 27 Nov 2007, in the Usenet newsgroup comp.os.linux.networking, in
    article , Bit Twister wrote:

    >Moe Trin wrote:


    >> OPINION: I don't like to use hostnames, as they are subject to spoofing.
    >> IP addresses are harder to spoof. Yes, in this case, it shouldn't be
    >> a major concern, but I go for blanket solutions.

    >
    >I hear where you are comming from. Was just trying to keep maintenance
    >down while changing LAN ip values.


    Very simple solution. Two lines - one with the old range, one with the
    new. The assumption is that your perimeter firewall is doing RFC2827
    or RFC3704 filtering ("internal" IP addresses can't be coming in as
    sources on the "external" interface), so having

    ALL: 192.168.1.
    ALL: 192.168.231.

    isn't going to be opening a massive hole.

    >ALL: .home.invalid
    >fails. So does ALL: wb.home.invalid, m2008.home.invalid


    OK - that rules out the space problem (hate to say how many times that
    has caught people.

    >>>$ cat /etc/host.conf


    >> If you drop the last two, does it work?

    >
    >No, and changing last two to off did not work either.


    OK

    >> OK. Assumption is no other lines containing those IP addresses.

    >
    >No,
    >$ grep 213 /etc/hosts
    >192.168.1.213 m2008.home.invalid m2008
    >
    >$ grep m2008 /etc/hosts
    >192.168.1.213 m2008.home.invalid m2008


    OK - that's another one that trips people.

    >> if you can 'ping -c 1 m2008.home.invalid' then tcpd _should_ work.

    >
    >Dang it, pings work, but NFS mount still fails with ALL: .home.invalid


    NFS... Something is back there, and I can't think what. Have you got
    any other daemon that is running out of xinetd? Because,

    >Nov 27 13:57:33 m2008 portmap[4702]: connect from 192.168.1.130 \
    > to getport(nfs): request from unauthorized host


    that's portmap bitching, not tcpd or xinetd.

    >$ cat /etc/exports
    >/local wb(rw,no_root_squash,sync)
    >
    >$ ping -c 1 wb
    >PING wb.home.invalid (192.168.1.130) 56(84) bytes of data.


    OK - gethostbyname is working

    >> or am I mis-interpreting your mail snip?

    >
    >It would be misleading


    Got it. I'm not used to that format. The %c being only the IP, it's not
    resolving for tcpd. Quick look - is there anything obvious in a packet
    dump? By that, I mean who is trying to talk to who - port numbers, etc.
    Rejections? Ignores? I'd be more trying to compare the packets
    between hosts.allow set with IPs verses net-names.

    >Open/no firewalls on both systems makes no difference.


    No, this is something else, and I can't think what it might be. There
    is something ringing an alarm bell for me, and it's related to NFS, not
    tcpd. But WHAT is it? At thing point, I don't know.

    Old guy

  8. Re: hosts.allow does not resolve names

    On Tue, 27 Nov 2007 20:23:26 -0600, Moe Trin wrote:
    > article , Bit Twister wrote:
    >
    > Very simple solution. Two lines - one with the old range, one with the
    > new.


    Yes, but I really wanted the names to work.

    It's kinda like doing the math problems which have the answers in the
    back of the book. I could work the ones with answers and could not
    work out the answer of the ones without the answers.


    > NFS... Something is back there, and I can't think what. Have you got
    > any other daemon that is running out of xinetd? Because,


    Nope.
    xinetd based services:
    cups-lpd: off
    cvs: off
    proftpd-xinetd: off
    rexec: off
    rlogin: off
    rsh: off
    rsync: off
    sshd-xinetd: off


    >
    >>Nov 27 13:57:33 m2008 portmap[4702]: connect from 192.168.1.130 \
    >> to getport(nfs): request from unauthorized host

    >
    > that's portmap bitching, not tcpd or xinetd.


    Yes, but hosts.allow changes is what is keeping portmap from allowing
    the nfs request.


    > Quick look - is there anything obvious in a packet
    > dump? By that, I mean who is trying to talk to who - port numbers, etc.
    > Rejections? Ignores? I'd be more trying to compare the packets
    > between hosts.allow set with IPs verses net-names.


    I'll get a packet dump tomorrow.


    >>Open/no firewalls on both systems makes no difference.


    It was a quick check, I was wondering if auth needed access and wanted
    to rule it out.


    > No, this is something else, and I can't think what it might be. There
    > is something ringing an alarm bell for me, and it's related to NFS, not
    > tcpd. But WHAT is it? At thing point, I don't know.


    Only other thing I thought of was:
    Three different versions of the NFS protocol are supported by the Linux
    NFS client: NFS version 2, NFS version 3, and NFS version 4. To mount
    via NFS version 2, use the nfs file system type and specify nfsvers=2.
    To mount via NFS version 3, use the nfs file system type and specify
    nfsvers=3. Version 3 is the default protocol version for the nfs file
    system type when nfsvers= is not specified on the mount command and
    both client and server support it. To mount via NFS version 4, use the
    nfs4 file system type. The nfsvers= keyword is not supported for the
    nfs4 file system type.

    That is why I went with
    [bittwister@wb ~]$ grep m2008 /etc/fstab
    m2008:/local /mlocal nfs rsize=32768,wsize=32768,timeo=14,intr 0 0

    Did not want to get buried in Kerberos and whatnot.

  9. Re: hosts.allow does not resolve names

    On Tue, 27 Nov 2007 20:23:26 -0600, Moe Trin wrote:
    > article , Bit Twister wrote:


    > Quick look - is there anything obvious in a packet dump?


    Not to my untrained eye. Here is fail followed by works.

    $ cat /etc/hosts.allow
    ALL: .home.invalid


    arp who-has m2008 tell wb
    arp reply m2008 is-at 00:a0:cc:e6:de:71 (oui Unknown)
    IP wb.57491 > m2008.sunrpc: S 1265898696:1265898696(0) win 5840
    IP m2008.sunrpc > wb.57491: S 301091153:301091153(0) ack 1265898697 win 5792
    IP wb.57491 > m2008.sunrpc: . ack 1 win 92
    IP wb.57491 > m2008.sunrpc: P 1:61(60) ack 1 win 92
    IP m2008.sunrpc > wb.57491: . ack 61 win 91
    IP m2008.sunrpc > wb.57491: P 1:33(32) ack 61 win 91
    IP wb.57491 > m2008.sunrpc: . ack 33 win 92
    IP wb.57491 > m2008.sunrpc: F 61:61(0) ack 33 win 92
    IP wb.34026 > m2008.sunrpc: UDP, length 56
    IP m2008.sunrpc > wb.57491: . ack 62 win 91
    IP m2008.sunrpc > wb.34026: UDP, length 28
    IP wb.39341 > m2008.sunrpc: S 1390155097:1390155097(0) win 5840
    IP m2008.sunrpc > wb.39341: S 429023936:429023936(0) ack 1390155098 win 5792
    IP wb.39341 > m2008.sunrpc: . ack 1 win 92
    IP wb.39341 > m2008.sunrpc: P 1:61(60) ack 1 win 92
    IP m2008.sunrpc > wb.39341: . ack 61 win 91
    IP m2008.sunrpc > wb.39341: P 1:33(32) ack 61 win 91
    IP wb.39341 > m2008.sunrpc: . ack 33 win 92
    IP wb.39341 > m2008.sunrpc: F 61:61(0) ack 33 win 92
    IP wb.34026 > m2008.sunrpc: UDP, length 56
    IP m2008.sunrpc > wb.39341: . ack 62 win 91
    IP m2008.sunrpc > wb.34026: UDP, length 28
    IP wb.47852 > m2008.sunrpc: S 1545191974:1545191974(0) win 5840
    IP m2008.sunrpc > wb.47852: S 599734652:599734652(0) ack 1545191975 win 5792
    IP wb.47852 > m2008.sunrpc: . ack 1 win 92
    IP wb.47852 > m2008.sunrpc: P 1:61(60) ack 1 win 92
    IP m2008.sunrpc > wb.47852: . ack 61 win 91
    IP m2008.sunrpc > wb.57491: F 33:33(0) ack 62 win 91
    IP wb.57491 > m2008.sunrpc: . ack 34 win 92
    IP m2008.sunrpc > wb.47852: P 1:33(32) ack 61 win 91
    IP wb.47852 > m2008.sunrpc: . ack 33 win 92
    IP wb.47852 > m2008.sunrpc: F 61:61(0) ack 33 win 92
    IP wb.34026 > m2008.sunrpc: UDP, length 56
    IP m2008.sunrpc > wb.47852: . ack 62 win 91
    IP m2008.sunrpc > wb.34026: UDP, length 28
    IP wb.54466 > m2008.sunrpc: S 1789680568:1789680568(0) win 5840
    IP m2008.sunrpc > wb.54466: S 834056044:834056044(0) ack 1789680569 win 5792
    IP wb.54466 > m2008.sunrpc: . ack 1 win 92
    IP wb.54466 > m2008.sunrpc: P 1:61(60) ack 1 win 92
    IP m2008.sunrpc > wb.54466: . ack 61 win 91
    IP m2008.sunrpc > wb.39341: F 33:33(0) ack 62 win 91
    IP wb.39341 > m2008.sunrpc: . ack 34 win 92
    IP m2008.sunrpc > wb.54466: P 1:33(32) ack 61 win 91
    IP wb.54466 > m2008.sunrpc: . ack 33 win 92
    IP wb.54466 > m2008.sunrpc: F 61:61(0) ack 33 win 92
    IP wb.34026 > m2008.sunrpc: UDP, length 56
    IP m2008.sunrpc > wb.54466: . ack 62 win 91
    IP m2008.sunrpc > wb.34026: UDP, length 28
    IP wb.40955 > m2008.sunrpc: S 2032104255:2032104255(0) win 5840
    IP m2008.sunrpc > wb.40955: S 1073076948:1073076948(0) ack 2032104256 win 5792
    IP wb.40955 > m2008.sunrpc: . ack 1 win 92
    IP wb.40955 > m2008.sunrpc: P 1:61(60) ack 1 win 92
    IP m2008.sunrpc > wb.40955: . ack 61 win 91
    IP m2008.sunrpc > wb.47852: F 33:33(0) ack 62 win 91
    IP wb.47852 > m2008.sunrpc: . ack 34 win 92
    IP m2008.sunrpc > wb.40955: P 1:33(32) ack 61 win 91
    IP wb.40955 > m2008.sunrpc: . ack 33 win 92
    IP wb.40955 > m2008.sunrpc: F 61:61(0) ack 33 win 92
    IP wb.34026 > m2008.sunrpc: UDP, length 56
    IP m2008.sunrpc > wb.40955: . ack 62 win 91
    IP m2008.sunrpc > wb.34026: UDP, length 28
    IP wb.43448 > m2008.sunrpc: S 2282608407:2282608407(0) win 5840
    IP m2008.sunrpc > wb.43448: S 1321319375:1321319375(0) ack 2282608408 win 5792
    IP wb.43448 > m2008.sunrpc: . ack 1 win 92
    IP wb.43448 > m2008.sunrpc: P 1:61(60) ack 1 win 92
    IP m2008.sunrpc > wb.43448: . ack 61 win 91
    IP m2008.sunrpc > wb.54466: F 33:33(0) ack 62 win 91
    IP wb.54466 > m2008.sunrpc: . ack 34 win 92
    IP m2008.sunrpc > wb.43448: P 1:33(32) ack 61 win 91
    IP wb.43448 > m2008.sunrpc: . ack 33 win 92
    IP wb.43448 > m2008.sunrpc: F 61:61(0) ack 33 win 92
    IP wb.34026 > m2008.sunrpc: UDP, length 56
    IP m2008.sunrpc > wb.43448: . ack 62 win 91
    IP m2008.sunrpc > wb.34026: UDP, length 28
    IP m2008.sunrpc > wb.40955: F 33:33(0) ack 62 win 91
    IP wb.40955 > m2008.sunrpc: . ack 34 win 92
    IP m2008.sunrpc > wb.43448: F 33:33(0) ack 62 win 91
    IP wb.43448 > m2008.sunrpc: . ack 34 win 92
    IP wb.47215 > m2008.sunrpc: S 2720007308:2720007308(0) win 5840


    $ cat /etc/hosts.allow
    ALL: 192.168.1.

    IP wb.47215 > m2008.sunrpc: S 2720007308:2720007308(0) win 5840
    IP m2008.sunrpc > wb.47215: S 1756948559:1756948559(0) ack 2720007309 win 5792
    IP wb.47215 > m2008.sunrpc: . ack 1 win 92
    IP wb.47215 > m2008.sunrpc: P 1:61(60) ack 1 win 92
    IP m2008.sunrpc > wb.47215: . ack 61 win 91
    IP m2008.sunrpc > wb.47215: P 1:33(32) ack 61 win 91
    IP wb.47215 > m2008.sunrpc: . ack 33 win 92
    IP wb.47215 > m2008.sunrpc: F 61:61(0) ack 33 win 92
    IP wb.0 > m2008.nfs: 0 null
    IP m2008.nfs > wb.0: reply ok 0 null
    IP wb.57085 > m2008.nfs: . ack 1754567466 win 92
    IP wb.730893333 > m2008.nfs: 44 null
    IP m2008.nfs > wb.57085: . ack 44 win 91
    IP m2008.sunrpc > wb.47215: F 33:33(0) ack 62 win 91
    IP wb.47215 > m2008.sunrpc: . ack 34 win 92
    IP m2008.nfs > wb.730893333: reply ok 28 null
    IP wb.57085 > m2008.nfs: . ack 29 win 92
    IP wb.57085 > m2008.nfs: F 44:44(0) ack 29 win 92
    IP wb.34026 > m2008.sunrpc: UDP, length 56
    IP m2008.nfs > wb.57085: F 29:29(0) ack 45 win 91
    IP wb.57085 > m2008.nfs: . ack 30 win 92
    IP m2008.sunrpc > wb.34026: UDP, length 28
    IP wb.34026 > m2008.32771: UDP, length 40
    IP m2008.32771 > wb.34026: UDP, length 24
    IP wb.919 > m2008.32771: UDP, length 96
    IP m2008.32771 > wb.919: UDP, length 76
    IP wb.3286482372 > m2008.nfs: 0 null
    IP m2008.nfs > wb.3286482372: reply Unknown rpc response code=2333925260 0
    IP wb.940 > m2008.nfs: . ack 1805589363 win 92
    IP wb.2198275900 > m2008.nfs: 44 null
    IP m2008.nfs > wb.940: . ack 44 win 91
    IP m2008.nfs > wb.2198275900: reply ok 28 null
    IP wb.940 > m2008.nfs: . ack 29 win 92
    IP wb.2215053116 > m2008.nfs: 44 null
    IP m2008.nfs > wb.2215053116: reply ok 28 null
    IP wb.2231830332 > m2008.nfs: 112 fsinfo fh Unknown/01000600C3E3BDC4312611D78B1CDF8C4D8D30D30000000000 00000000000000
    IP m2008.nfs > wb.2231830332: reply ok 84 fsinfo rtmax 131072 rtpref 131072 wtmax 131072 wtpref 131072 dtpref 4096
    IP wb.2248607548 > m2008.nfs: 112 getattr fh Unknown/01000600C3E3BDC4312611D78B1CDF8C4D8D30D30000000000 00000000000000
    IP m2008.nfs > wb.2248607548: reply ok 116 getattr DIR 40755 ids 0/0 sz 4096
    IP wb.2265384764 > m2008.nfs: 112 fsinfo fh Unknown/01000600C3E3BDC4312611D78B1CDF8C4D8D30D30000000000 00000000000000
    IP m2008.nfs > wb.2265384764: reply ok 84 fsinfo rtmax 131072 rtpref 131072 wtmax 131072 wtpref 131072 dtpref 4096
    IP wb.2282161980 > m2008.nfs: 112 getattr fh Unknown/01000600C3E3BDC4312611D78B1CDF8C4D8D30D30000000000 00000000000000
    IP m2008.nfs > wb.2282161980: reply ok 116 getattr DIR 40755 ids 0/0 sz 4096
    IP wb.940 > m2008.nfs: . ack 457 win 92

  10. Re: hosts.allow does not resolve names

    On Wed, 28 Nov 2007, in the Usenet newsgroup comp.os.linux.networking, in
    article , Bit Twister wrote:

    >Moe Trin wrote:


    >> Very simple solution. Two lines - one with the old range, one with the
    >> new.

    >
    >Yes, but I really wanted the names to work.


    Well, they should. Your syntax appears (to me) to be correct.

    >It's kinda like doing the math problems which have the answers in the
    >back of the book. I could work the ones with answers and could not
    >work out the answer of the ones without the answers.


    By the time I got to that stage, the problems were quite complex, and
    there's the answer, but how the heck did they get that? ;-)

    >> Have you got any other daemon that is running out of xinetd?


    >Nope.
    >xinetd based services:
    > cups-lpd: off
    > cvs: off
    > proftpd-xinetd: off
    > rexec: off
    > rlogin: off
    > rsh: off


    You wonder why they even include the Berkeley 'r' commands any more. If
    you are on an isolated network that is fully trusted, they're OK, (and
    exceptionally convenient), but they are _so_ easy to abuse.

    >> that's portmap bitching, not tcpd or xinetd.

    >
    >Yes, but hosts.allow changes is what is keeping portmap from allowing
    >the nfs request.


    The thought was to try another xinetd service to see if the reactions
    were the same. I could be wrong, but just enabling the service in
    xinetd EVEN IF THE SERVER ISN'T INSTALLED should allow testing of tcpd.
    This would show up in the server xinetd logs.

    >Only other thing I thought of was:
    > Three different versions of the NFS protocol are supported by the
    > Linux NFS client:


    I don't _think_ so.

    >That is why I went with
    >[bittwister@wb ~]$ grep m2008 /etc/fstab
    >m2008:/local /mlocal nfs rsize=32768,wsize=32768,timeo=14,intr 0 0


    Not sure about the timeo option, but that's not the problem we're seeing.

    >Did not want to get buried in Kerberos and whatnot.


    I don't know why ;-)

    Old guy

  11. Re: hosts.allow does not resolve names

    On Wed, 28 Nov 2007, in the Usenet newsgroup comp.os.linux.networking, in
    article , Bit Twister wrote:

    >Moe Trin wrote:


    >> Quick look - is there anything obvious in a packet dump?

    >
    >Not to my untrained eye. Here is fail followed by works.


    >arp reply m2008 is-at 00:a0:cc:e6:de:71 (oui Unknown)


    [compton ~]$ etherwhois 00:a0:cc
    00-A0-CC (hex) LITE-ON COMMUNICATIONS, INC.
    00A0CC (base 16) LITE-ON COMMUNICATIONS, INC.
    720 S. HILLVIEW DRIVE
    MILPITAS CA 95035
    UNITED STATES
    [compton ~]$

    Your sniffer is old - that OUI has been out there for at least 8 years.

    [snip 'ALL: .home.invalid' list]

    Nothing is jumping out at me. Basically, three attempts to connect.

    >ALL: 192.168.1.


    No obvious difference in the first conversation, but this continues.
    Several of the lines look weird, but the stuff is working. (I haven't
    sniffed NFS in several years - so I'm awfully rusty. Sorry)

    Old guy

  12. Re: hosts.allow does not resolve names

    On Wed, 28 Nov 2007 19:35:19 -0600, Moe Trin wrote:
    > article , Bit Twister wrote:
    >> rlogin: off
    >> rsh: off

    >
    > You wonder why they even include the Berkeley 'r' commands any more. If
    > you are on an isolated network that is fully trusted, they're OK, (and
    > exceptionally convenient), but they are _so_ easy to abuse.


    I hear you, I liked rlogin on just my node on my accounts (browser,
    usenet, email...) .

    Mandriva went and requires Kerberos for r*'s use a year or so ago.
    Guess I'll have to take it out of the post install commands.


  13. Re: hosts.allow does not resolve names

    On Wed, 28 Nov 2007 19:36:25 -0600, Moe Trin wrote:
    > On Wed, 28 Nov 2007, in the Usenet newsgroup comp.os.linux.networking, in
    > article , Bit Twister wrote:
    >
    >>Moe Trin wrote:

    >
    >>> Quick look - is there anything obvious in a packet dump?

    >>
    >>Not to my untrained eye. Here is fail followed by works.

    >
    >>arp reply m2008 is-at 00:a0:cc:e6:de:71 (oui Unknown)

    >
    > [compton ~]$ etherwhois 00:a0:cc
    > 00-A0-CC (hex) LITE-ON COMMUNICATIONS, INC.
    > 00A0CC (base 16) LITE-ON COMMUNICATIONS, INC.
    > 720 S. HILLVIEW DRIVE
    > MILPITAS CA 95035
    > UNITED STATES
    > [compton ~]$
    >
    > Your sniffer is old - that OUI has been out there for at least 8 years.


    What can I say, used wireshark saved run to file. It was binary.
    Installed tcpdump and had it convert to ascii.

    >
    > No obvious difference in the first conversation, but this continues.
    > Several of the lines look weird, but the stuff is working. (I haven't
    > sniffed NFS in several years - so I'm awfully rusty. Sorry)


    That's Ok, and I do apprecate your time and effort. Guess I'll settle
    for using ip numbers.


  14. Re: hosts.allow does not resolve names

    Bit Twister writes:


    > I imagined it would work like man hosts.allow indicates
    >
    > The access control language implements the following patterns:
    >
    > A string that begins with a . character. A host name is
    > matched if the last components of its name match the specified
    > pattern. For example, the pattern .tue.nl matches the host
    > name wzv.win.tue.nl.
    >
    > then looking through man -s 5 hosts_access the example
    >
    > /etc/hosts.allow:
    > ALL: LOCAL @some_netgroup
    > ALL: .foobar.edu EXCEPT terminalserver.foobar.edu
    >
    >
    > would suggest it should work. :-D
    >
    > Feel free to look through the rest of the thread for more info.



    Several things come to mind. 1) It depends on what is implementing
    tcpwrappers. Some programs link against libwrap, and this is what the
    manpages above talk about. Some programs emulate tcpwrappers, but just
    look at the hosts.* files and don't link libwrap. 2) RPC portmapper must
    use IP numbers, not hostnames. It says this in the portmap manpage
    here:

    You have to use the daemon name portmap for the daemon name (even if the
    binary has a different name). For the client names you can only use the
    keyword ALL or IP addresses (NOT host or domain names).

    3) You can still use tcpd with xinetd. Just turn off xinetd's libwrap,
    and use right flags in the xinetd.conf file. server will be tcpd, and
    use NAMEINARGS, NOLIBWRAP.



    --
    [** America, the police state **]
    Whoooose! What's that noise? Why, it's US citizen's
    rights, going down the toilet with Bush flushing.
    http://www.wired.com/politics/securi...007/08/wiretap
    http://www.hermes-press.com/police_state.htm

+ Reply to Thread