HANK@TAUNIVM.BITNET.UUCP (04/07/87)
I have a feeling this posting might generate quite a bit of
philosphical talk - but I would like to request in advance that I am
not interested in feelings and/or emotions but rather technical solutions.
With that behind me I would like to know about solutions in Tcp/Ip for
the following two areas:
1) Access control:
A) On a system level: How do I go about restricting the use of users
from using Tcp/Ip? I realize that every operating system may have
a different solution but I am interested in hearing concepts and
whether anyone is actually doing it.
B) On a gateway level: If I have a gateway (say something like Bridge
or cisco) do I have any capability of performing any sort of access
control? If yes, is this access control based on connected machines
or can I even exercise access control on a user level (i.e. restrict
FTP or TELNET to a certain group of users on a certain machine).
2) Accounting:
A) System level: Is there any accounting package that can measure things
like packet transfer (FTP always tells you how many Kb/sec you sent
so it isn't impossible to figure out) levels and Telnet connect time?
B) Gateway level: Is there some gateway or monitoring PC that can do
accounting? Is the accounting per system or can it be broken down
per user (I assume very difficult to do)?
As a side note, anyone who is up on ISO: what is the status of accounting
and access control in ISO? Has it even been thought of?
Thanks in advance,
HankCERF@A.ISI.EDU.UUCP (04/07/87)
Hank, Little has been developed for access control and accounting. Some gateways (e.g. BBN?) can filter IP packets based on source/destination address. I don't know of any which filter with knowledge of the protocol being used. I do not know of any gateways that provide accounting data, although such information as packet counts from a given host can be obtained from, e.g. the ARPANET. I would not be surprised to hear that some gateways and even some bridges keep some statistics about traffic loads, but probably not by source or destination. Thus far, the TCP/IP software has gone into private or gov't-owned systems which have not demanded much inthe way of accounting (or of access control). Vint
LYNCH@A.ISI.EDU.UUCP (04/07/87)
Hank, On the "system" side is is entirely up to the operating system that runs the hardware interface to the network. I have worked on a system that did enforce access controls on a per user basis to the network interfaces that were attached to it. Since the operating system allready had a strong notion of access control it was not dificult to add in the support for network access. But, it certainly is true that we needed the source code to everything in sight to make it all happen. The early days of networking had a notion of what it was that was being hooked up to the netowrk: a timesharing system with a responsible adminstration ensuring some kind of access restrictions or at least a place to call to register a complaint. Today's technological advances have made is so that everyone on earth is a "timesharing system administrator". Clearly the "responsibility" for hooking up to the network has to be placed elsewhere. The owner of the "cable" is teh obvious choice, but that does not take into account radio based networks... IN short: It looks like the "gateway owners" are going to have to become the administrators of the future! Yikes, back to the future??? Dan -------
hedrick@TOPAZ.RUTGERS.EDU.UUCP (04/08/87)
There are fairly widely-available patches to Unix to allow you to control access to TCP. It restricts the ability to open a network connection based on the network number. That is, you create a list of "local" networks. (We assume you want users to be able to access local machines, and are concerned only about the Arpanet, etc. If you want to restrict all access, you can make this list empty.) Attempts to open connections to networks not in this list fail unless the user is in a certain specified user group. However this does not control daemons. E.g. mail will still work because the mailer has to have network access. You will need to insert the access control in sendmail also. We have done all of this stuff in the past, but are not doing it now. It is nearly impossible to control mail. There are now so many gateways, that you can always find some machine on the local network that will forward your mail to the Arpanet for you. Not to mention UUCP or Bitnet to Arpanet gateways. However other services should work. Cisco gateways allow access control lists to be attached to various operations. This includes incoming and outgoing telnet connections (applied only when the connection opens), and packets going out a specified interface. We have an access control list on our Arpanet gateway. The lists can use wildcards or individual hosts, however for performance reasons there is a limit to the number of wildcard conditions you can have. I know that people are working on accounting and performance monitoring of the type you mention, but I don't know of anything that is available now. Of course most gateways and TCP/IP implementations maintain packet and event counts of various sorts. So if you just mean counts of packets per interface in and out, the Unix TCP/IP implementations and Cisco gateways do this. I presume other vendors' gateways do as well.
howard@cos.UUCP.UUCP (04/08/87)
In article <8704071037.AA04224@ucbvax.Berkeley.EDU>, HANK@TAUNIVM.BITNET (Hank Nussbacher) writes: > With that behind me I would like to know about solutions in Tcp/Ip for > the following two areas: > As a side note, anyone who is up on ISO: what is the status of accounting > and access control in ISO? Has it even been thought of? Here are some answers, or directions, for the questions raised, but from an ISO context: The ISO OSI Management Framework, a draft appendix to the OSI Reference Model, defines five missions in OSI management: configuration, fault, performance, security, and accounting management. This is an architectural definition of the problem, not an implementation specification. Associated with this architecture are the Common Management Information Service (CMIS) and the Common Management Information Protocol (CMIP) definitions, which describe mechanisms for management entities to exchange general management information. There is a subtle distinction between "security" and "security management". Such mechanisms as link or end-to-end encryption are security mechanisms, part of the data link or transport layer definitions. If these mechanisms are not implemented, there is no need to manage them and thus no need for security management. Once you decide to have them, security management then logically should exist to provide such supporting services as breach attempt logging, key distribution, etc. Similar distinctions apply in accounting; accounting data collection is a layer function, but data distribution is a management function. > 1) Access control: >On a system level: How do I go about restricting the use of users > from using Tcp/Ip? >On a gateway level: If I have a gateway (say something like Bridge > or cisco) do I have any capability of performing any sort of access > control? If yes, is this access control based on connected machines > or can I even exercise access control on a user level (i.e. restrict > FTP or TELNET to a certain group of users on a certain machine). Association Control Service Elements (ACSE --formerly CASE) , a layer 7 function, does deal with access control to OSI applications. Other applications, such as FTAM (File Transfer, Access, and Management) do have their own access control mechanisms, including optional anonymous user access. > 2) Accounting: > System level: Is there any accounting package that can measure things > like packet transfer (FTP always tells you how many Kb/sec you sent > so it isn't impossible to figure out) levels and > Telnet connect time? ANSI standards X3.102 and X3.141, the latter in publication, define general models for describing such things as packet transfer time; draft ANSI work in the T1Q1.3 committee and the Question 29 Rapporteur's group in CCITT Study Group VII also are dealing with such problems. Neal Seitz, at the U.S. Commerce Department's Institute for Telecommunications Sciences in Boulder, CO, is the chair of the latter groups and a major author of the preceding standards. He has some public domain software available from his group (telephone 303-497-3106; I don't have a net address). > Gateway level: Is there some gateway or monitoring PC that can do > accounting? Is the accounting per system or can it be broken down > per user (I assume very difficult to do)? There are general, hardware-based monitoring systems which can do this. They are not cheap, and the mindset of their sales forces is primarily dealing with response time measurement in IBM 3270 and similar environments. Nevertheless, systems made by Tesdata (also the OEM for Infinet and Paradyne), Avant-Garde, and Dynatech do have some ability to track applications, users, or other high-level entities. Several] years ago, I did the first Tesdata design, and know that it's quite internally capable of tracking network addresses, user ID's, etc.
NS-DDN@DDN3.ARPA.UUCP (04/08/87)
The UCLA ACP and its derivatives are very concerned about access control, and less concerned about accounting. The public domain code has a pseudo-service called PACCESS which is invoked at choice places in the package to inquire as to the efficacy of an end user's requests. Unless the installer does some coding, the barn door is wide open for using TCP, UDP, TELNET, etc., and whatever security system installed on MVS controls file access. UCLA has an interface to ACF2 which is based upon a local interface SVC, and their version of PACCESS can be conditionally assembled. However, the interface involves some pretty trick UCLA MVS mods and would require substantial systems programming expertise and time to massage into another environment. DDN/MVS features a modified version of PACCESS which uses a table of user-ids, passwords, and user attributes to control user access. Customers code macros for each user, reassemble the table, and link it into the commutator. This controls VTAM accesses to the internet, use of some privileged TELNET services, authorizations to receive SMTP mail on a mailbox basis, and FTP file accesses on a high-level DSNAME qualifier basis. For accounting, the public domain version sports logic which accumulates CPU time used by pseudo-tasks or counts ptask dispatches (the default). However, no provision is made for reporting this information to an accounting system. Here again, it is expected that an experienced systems programmer is installing the ACP into a sophisticated MVS shop. The FTP logic has a place (FTPWACR - Write ACcounting Record) where an SMF record could be cut, but only generates an internal WTO-type messaage describing the FTP request. DDN/MVS currently provides no enhancements to the accounting support. Dave Craig Network Solutions, Inc.
dcrocker@engr.ub.COM.UUCP (04/10/87)
Newsgroups: mod.protocols.tcp-ip Subject: Re: Access control and accountability Summary: Expires: References: <8704081259.AA17700@topaz.rutgers.edu> Sender: Reply-To: dcrocker@ubvax.UUCP (Dave Crocker) Followup-To: Distribution: world Organization: Ungermann-Bass, Inc., Santa Clara, Ca. Keywords: In article <8704081259.AA17700@topaz.rutgers.edu> hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) writes: >... You will need to insert the access control in >sendmail also. We have done all of this stuff in the past, but are >not doing it now. It is nearly impossible to control mail. There are >now so many gateways, that you can always find some machine on the >local network that will forward your mail to the Arpanet for you. Not >to mention UUCP or Bitnet to Arpanet gateways... The MMDFII mail transport system, used by CSNet and distributed with 4.3BSD, has considerable path-filtering based security. You can prohibit users, networks or hosts from sending to any specified host or network. While this requires a cooperating set of internal MMDF's to enforce filtering pervasively, rather than simply at the boundaries, one would assume that a security mechanism would not be used unless the requirement were fairly severe. Dave P.S. You are correct that statistics gathering features are present in other vendors' IP Routers.