telnet access denied

[Peter Kielbasiewicz]

I have a problem telnetting into a 10.20 machine which is set up for a new network.
We are using /etc/networks to configure our network ranges and /etc/nsswitch.conf is set to 'networks: files [NOTFOUND=return UNAVAIL=return]'
/etc/networks looks like this
myCompany 130.143.80
myCompany 130.143.81
. . .

Then /var/adm/inetd.sec has lines like
telnet allow myCompany loopback

When I put the IP addresses directly into inetd.sec I can telnet into the system. When I am using the /etc/network approach access is denied.
This is strange because in our current network we are using the /etc/network approach without any problems.

[Shannon Petry]

While not that familiar with using a "networks" file, looking at the man page your format is incorrect.
man networks shows 3 required fields
"official name" IP Alias

Try adding an alias field on 1 machine and see if it works. Inet is very picky about file formats and may be bailing when the alias field is absent.

Regards,
Shannon

[Wodisch_1]

Hi,

...and "inetd.sec" expects the format "1.2.3.*" IIRC (not "1.2.3")...

HTH,
Wodisch

[Peter Kielbasiewicz]

I tried changing /etc/networks to something like:
myCompany 130.143.80.* myalias
...
But it did not change anything.
I then changed inetd.sec to
telnet allow myCompany loopback 130.134
and it works.
This shows me that the problem must be something else but not with aliases and or asterisks.
As I stated in my original message, we have our current network running with the same /etc/networks approach and it works without problems.
I attached the head of our current /etc/networks for reference.

My feeling is, that the /etc/networks file is not read at all but I have no clue why so.

[Jon Finley]

You "should" be able to use

telnet allow myCompany loopback 130.134.8*

and at least restrict the access some.


Jon

[Shannon Petry]

Okay, first you need to use one or the other. Are you using the networks or the ip address for auth?
If your using the networks then forget about coding the ip into inetd.sec

Now, I think someone elses answer may have confused you. If you want to fix the "/etc/networks" file then the format is
ProperName IP Alias
MyNet 10.1.1 MN
You can NOT put an asterisk into the /etc/networks file.

If you have a bad field in networks, it will not be read by inet. Same is true for netgroups.
While in networks the alias field on my Sun's are optional, the HP's may be more particular.

Second, I dont think you can use networks for securing inetd. I think your confusing networks and netgroups. inetd supports the same getnetbyname and getnetbynumber as NFSD for which I have never seen /etc/networks used or supported, but rather a network number, netgroup name, ip, or hostname. (Solaris supports a .domain feature as well, but that's another discussion). I could very well be wrong on this.

When you say your using the /etc/network approach on your network without any problems, what excatly are you using it for? (/etc/networks is the precursor to /etc/netgroups, so not widely used any more)

Regards,
Shannon

[Peter Kielbasiewicz]

Hi Shannon,
I do only want to use /etc/networks in the same manner as we are using it now in our running LAN.
I just played around with entries in inetd.sec to test some of the answers I got.

As I stated in my first reply I already tested putting an Alias after every network entry an it did not work.
In our actual LAN we do not have aliases and it works without them without problems so I think it is not a mandatory field.

In HP-UX the file /etc/nsswitch.conf can be configured by using SAM and when you select files instead of NIS it creates the /etc/networks entry.
Thus I think /etc/networks is still used by HP-UX as the central point to define various IP ranges as a common network, thus avoiding long lists after every service in inetd.sec.

[Daimian Woznick]

The inetd.sec file gets the network address by gethostbyaddr() or getnetbynumber(). So the approach of placing the name myCompany in the inetd.sec file should work. However, in your networks file you have two entries with the same name. Try changing this to agilent1 and agilent2 and see if it works better.

You probably already did this, but check your services file to ensure the entry for telnet is in the correct format.

[Daimian Woznick]

What kind of messages are being placed into the syslog file?

[Wodisch_1]

Hi again,

AFAIK you cannot have ranges and/or wildcards in "/etc/networks", but you need those in "/var/adm/inetd.sec". So you cannot use the *network names* in "inetd.sec" :-(

Sorry,
Wodisch

[Daimian Woznick]

Wodisch,

The following is from the man page of inetd.sec on a 10.20 server.

The following entry denies rlogin access to host cory.berkeley.edu,
any hosts on the network named testlan, and the host with internet
address 192.54.24.5:

login deny 192.54.24.5 cory.berkeley.edu testlan

To me, this example means that the testlan (variable if you will) can be used in the inetd.sec file. If I am wrong in this assumption please tell me.

[Peter Kielbasiewicz]

To clear things up a bit here are some details.
In our company LAN we have several class B and class C networks worldwide and ALL services in inetd.sec are configured using the scheme:

service allow myCompany loopback

The network name "myCompany" is defined in /etc/networks on MULTIPLE lines as shown below

myCompany X1.Y1 # class B network 1
myCompany X2.Y2 # class B network 2
myCompany X3.Y3.Z3 # class C network 1 myCompany X3.Y3.Z4 # class C network 2
...

This scheme works fine and without any problems.
No aliases, asterisks or anything the like are used and everything is OK.
We are running this scheme for years now.

We are trying to set up a seperate Test LAN with a few class C networks.
So I copied our actual scheme to the hosts in the test LAN but it seems that the entries in /etc/networks are not processed at all.
All I get in the syslog is "..telnet/tcp: Access denied for ..."
As I stated before, I can grant access by adding the ip ranges into inetd.sec.
Because there are so many entries in inetd.sec this makes the file very awkward and error prone. It is also essential to understand the problem and not look for a workaround because there may be other side effects caused by this problem.