Thank you for your insightful reply to my reply.
I agree with both Ben Nagy's comment that the programmers, of an HTTP service for managing a network device, are doing a poor job security-wise and also with your statements (a copy of which are included after my reply).
I find that the security considerations appropriate for the management of network products such as Wireless Access Points, DSL/Cable routers, uninterruptable power supplies (UPS's), printer servers, etc. for the small office/home office (SOHO) environment is being neglected by the vendors. The average purchaser of SOHO products is usually not very technically savvy. Thus, I can understand the desire to provide a browser interface to make it easier for the majority of the purchasers. Because of this, I think the vendors should do a better job of ensuring that the environment created by their products are not so readily exploitable. I believe that the security community needs to continue to educate both the vendors and the public for increased attention to security within both hardware and software products. I think it is the best way to finally achieve such a goal.
Beginning in 1993, when I was a corporate information security officer for a major US bank with a global presence, I began distributing a version of the following white paper (see below) on router security requirements. I believe that much of these requirements carry over to all the newer network devices that have joined the scene since then.
In summary, I think the security community should push for a minimum baseline security capability that any network device should have. I think the firewall list is a good place to start the discussion on what that capability should be. It appears to me that your "off-topic" message is part of such a discussion.
Regards;
Marc Mandel
White Paper Subject:
Issued by:
INTRODUCTION
Many of my clients' networks are private voice, data, and video telecommunications networks spanning their operations nationally or around the globe. Their data environments are composed of corporate owned Local Area Network (LAN) wiring at business sites linked by Wide Area Network (WAN) circuits contracted from long distance carriers. The interconnection of LANs to WANs is normally accomplished (or planned to be) by routers. Protocols routed are AppleTalk, DECnet, Novell IPX, OSI, and TCP/IP.
PROBLEM STATEMENT
Concern has arisen that, given the expansive environments of my clients' networks and the distributed network management necessary to maintain such systems seven days a week, twenty-four hours per day, network security has an unacceptable risk. Notably the threat of a loss of service due to unauthorized personnel gaining access to one or more routers. This concern derives from the fact that access control, in most routers, currently is normally limited to two group ids (operative and administrative) and their associated passwords. While link encryption can secure WAN circuits, data on LAN wiring can be eavesdropped by anyone who can gain access. Such access can be accomplished by physical access to either the wiring or a node connected to a LAN. Access can also be obtained by remote mechanisms. These include both dial-in and external network connectivity. Therefore, given the numerous methods for accessing the network and the ease by which the local network segment can be passively monitored, the author believes that utilization of group user ids coupled with fixed passwords is insufficient security.
PROPOSED SOLUTION
In response to the above problem, the author has proposed that routers be modified to support discretionary access control with individual accountability:
1) a maximum of fifty (50) individual user ids per machine
2) the following eight (8) group ids per machine -
a) Security Administration (SA)
b) Audit Administration (AA)
c) Global Network Administration (GNA)
d) Global Network Operations (GNO)
e) Regional Network Administration (RNA)
f) Regional Network Operations (RNO)
g) Local Network Administration (LNA)
h) Local Network Operations (LNO)
3) SA defined authentication approach on a per user id basis -
a) fixed password
b) random password generator (RPG);
such as Security Dynamics' SecurID Card
c) Kerberos ticket authentication
via DES or Public Key algorithms
4) AA defined auditing -
a) recording user id, date, time, source node of successful login [On/Off]
b) recording user id, date, time of logoff/disconnect [On/Off]
c) recording of date, time, source node of failed logins [On/Off]
d) recording of user id, date, time when system configuration changes [On/Off]
e) recording of user id, date, time, name(s) of parameter or function modified
when system configuration changes [On/Off]
f) recording of user id, date, time of any executables
[All On/On by User Id/All Off]
g) recording of user id, date, time of any writes [All On/On by User Id/All Off]
h) recording of user id, date, time of any reads [All On/On by User Id/All Off]
i) direction of auditing information to specified node(s)
j) local retention of the last fifteen (15) minutes of activity if a, b, c, & d is On.
5) Security, Audit, and Network Administration must be remotely managed via a
hierarchy of Simple Network Management Protocol (SNMP) managers. The
SNMP managers will be executing on UNIX workstations. The SNMP clients
(or agents) will be on the routers. Both software versions must support
Secure SNMP (a.k.a. SNMP 2).
Regarding the eight (8) group ids listed in item 2, the job functions of the
different group ids are:
SA
AA
GNA
GNO
RNA
RNO
LNA
LNO
Note that it is intended that each of the fifty (50) individual user ids (item 1) must be associated with at least one (1) of the eight (8) group ids (item 2). This permits discretionary access controls to be constructed on a group basis while still providing individual accountability.
In addition to the above requirements being applied to routers, the author also believes that such requirements should also be imposed upon:
The author welcomes any and all feedback/constructive criticisms on this white paper.
At 08:35 PM 06/03/2002 +0200, Mikael Olsson wrote:
(again: you probably shouldn't listen to a word I'm saying)
"Marc E. Mandel" wrote:
>
> [firewall management interfaces...]
>
> - An https management interface where both the firewall and the
> administrator(s) have valid certificates.
Hmm.. for what kind of environment? Aren't you worried about all the
client-side vulnerabilities in browsers?
> - a secure version of Simple Network Management Protocol (SNMP). SNMP
> Version 2 was designed to provide secure management.
RFC1445, "Administrative Model for SNMPv2":
4.5. Public Key Configuration
This section presents an example configuration predicated upon
a hypothetical security protocol. [...]
Nice. Hypothetical.
5. Security Considerations
In order to participate in the administrative model set forth
in this memo, SNMPv2 implementations must support local, non-
volatile storage of the local database of party information.
Accordingly, every attempt has been made to minimize the
amount of non-volatile storage required.
In my book, that's not a security consideration.
(Yes, that's the full text)
For encryption, plain old DES is used. No good.
It also uses a _constant_ IV. Useless.
Also, it's all based on static keys. Where are the session keys?
Break one old session and you get unlimited access to future
messages.
From a cryptography perspective, the SNMP security protocol is
a complete disaster. Maybe, _maybe_, it's good enough for some
uses (for some value of "some"), but _I_ for one don't want
code for SNMP write access anywhere near my firewalling process,
let alone let it make changes to my policy.
(And don't get me started on the inherent complexity of the
entire SNMP protocol. Recent incidents speak for themselves,
I believe.)
> - an Secure Shell (SSH) implementation that supports both secure
> telnet and secure ftp.
SSH has problems too; perhaps not so much design-wise as complexity-
wise, which the recent and not-so-recent stream of bugs in various
SSH implementations has shown us.
Granted, these problems could probably be worked around by writing
a minimalistic implementation that scraps SSHv1 compatibility
and a few other things that one really shouldn't need in a
firewall.
Then again, if I had to choose from the above three, SSH would
definately be my choice.
Regards,
Mikael Olsson
--
Mikael Olsson, Clavister AB
Storgatan 12, Box 393, SE-891 28 ÖRNSKÖLDSVIK, Sweden
Phone: +46 (0)660 29 92 00 Mobile: +46 (0)70 26 222 05
Fax: +46 (0)660 122 50 WWW: http://www.clavister.com
"Senex semper diu dormit"
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
For Account Management (unsubscribe, get/change password, etc) Please go to:
http://lists.gnac.net/mailman/listinfo/firewalls
