Securing Management of the Firewall - SNMP and other protocols -.
Secure SNMP management was the question last week on the Great Circle
mailing list, that's why I would like to give my opinion on the possible
ways to achieve secured management of a Firewall through SNMP or other
protocols.
Any comments are welcome. Distribution unlimited.
Before looking through SNMP security we should look at the overall
security policy which must be the beginning before any Firewall and
security products setup. I am going to focus on Management Security
Policy and especially logical access control to the firewall management
software and the management station. Physical access control to the
firewall or the management station is out of the scope of this paper
- e.g. password versus one-time-password access control to the management
station is out of the scope of this paper -.
Terminology : In the following,
- 'untrusted' means any untrusted equipment towards the firewall management
software and the management station - i.e. even the internal network - in
firewall speaking - is supposed untrusted;
- a 'management station' is a workstation where a 'management software' is
running to manage the firewall and maybe other equipment;
- a 'managed node' is an equipment managed by a management station;
- the 'agent' is the management software running at the managed equipment;
- a 'management task' is any task required to achieve management of a managed
node with a management station such as configuration, monitoring, etc..;
- state-of-the-art cryptography is a set of cryptographic procedures fitting
an overall security policy which definition is out of the scope of this paper.
Whatever management protocol you choose - TELNET, File transfer, X-Windows,
HTTP/HTML, SNMP or any other existing or further management protocol, the
different main solutions for securing access to management tasks are :
1 - Physical isolation between the management station and the managed node.
This isolation can be done by running the management software on the same
physical system and by filtering any external access to management tasks
- i.e. the management is local. Optionally the firewall may accept management
tasks of other equipment through the firewall. The security policy may require
screened screens to improve confidentiality.
----------------------
! Management Station !
----------------------
! Managed Firewall !
----------------------
! ! !
Attached Untrusted Networks
With Possible Other Managed Objects
by the Management Station.
2 - Logical isolation using a dedicated network for management tasks - i.e.
out of band management -. Management tasks can be done only from the
physical management network. In this case, the firewall filters every
management command from any other network. Optionally the firewall may
accept management tasks of other equipment from the management station
through the firewall. The security policy may require physical isolation of
each piece of equipment of the dedicated management network - i.e. Hubs,
cables, physical location, physical access control -.
----------------------
! Management Station !
----------------------
!
! Out of Band Dedicated
! and Trusted Management Network
!
----------------------
! Managed Firewall !
----------------------
! ! !
Attached Untrusted Networks
With Possible Other Managed Objects
by the Management Station.
3 - An extension of the previous scheme is one or more trusted networks
where passwords can flow in the clear and where only external network
isolation is required.
In this case the management station can use password based authentication,
the firewall filters every management command from any other network. As a
matter of fact, what about setting a high security level for the firewall
management if you trust all users on the network ? If some trusted user
wants to penetrate any host on the trusted network he doesn't need to break
the firewall security.
The security policy may require physical isolation of all equipment of the
trusted network - i.e. Hubs, cables, physical location, physical access
control -.
----------------------
! Management Station !
----------------------
!
!
! ------------------
!-----------------! Trusted Client !
! ------------------
!
! ------------------
!-----------------! Trusted Server !
! ------------------
!
! Trusted Networks
!
----------------------
! Managed Firewall !
----------------------
! ! !
Attached Untrusted Networks
With Possible Other Managed Objects
by the Management Station.
4 - The management task is to be done via untrusted networks - e.g.
corporate management through WAN, outsourced management, in depth security
policy -. Although untrusted the network should be available. If enough
availability cannot be warranted - e.g. the network fears denial of service
attacks -, this solution is not acceptable. For this solution, the
management protocol must be enforced with high level cryptographic to the
network or transport level - i.e. virtual private network/transport
services - or to the management protocol itself.
This solution is of course the most expensive not because of the cost of
the solution itself but because it requires appropriate algorithm choices,
key length choices and management, comprehensive and coherent overall
security policy for all secured equipment. Physical access control to the
firewall and the management station must be provided from untrusted
environments - e.g. leased lines, offices, etc. -.
The minimum virtual private network service required for this solution to
work is state-of-the-art signature of all management messages,
authentication of the management station's user preferably to management
station only authentication. Optionally the security policy may require
confidentiality but if this option is chosen, confidentiality for other
information services is also required - e.g. DNS, ECHO Protocols, Network
Information Services, etc.-. Remember that management confidentiality is
only - security through obscurity - but for key exchange of course which
always requires encryption.
----------------------
! Management Station !
!Message Cryptography!
----------------------
!
!
! --------------------
!-----------------! Untrusted Client !
! --------------------
!
! --------------------
!-----------------! Untrusted Server !
! --------------------
!
! Untrusted Networks
!
----------------------
!Message Cryptography!
! Managed Firewall !
----------------------
! ! !
Attached Untrusted Networks
With Possible Other Managed Objects
by the Management Station.
The differences between these management schemes is the level of security
and ... the price - the more security you want the more you must pay for -.
The last solution can be used in any scheme even for the first one for
those who think that it is necessary to cipher information between local
API function calls - i.e. some debugging tool could log each bit of data
and send them to the outside -.
In all cases, it is necessary before deciding on any security measure to
think about the overall security policy - e.g. what you really need and
now -. A coherent security policy is always better than politically visible
security measures which can lead to excessive trust from users and can lead
to security breaks.
It is not worth making a strongbox bomb-proof using a ten-inch armor plate
if a smoke detector can automatically empty the strongbox.
5 - The second important problem to deal with concerns the simultaneous
management of the firewall by many stations with different access rights
- e.g. a keymaster, a security policy master, a system master, a user
managing his own account -. This problem can be solved only by the
management protocol itself either in the agent either through a trusted
management proxy.
Now, how does SNMP deal with all these schemes ?
SNMP can be used alone or in conjunction with other protocols to offer a
good solution to all schemes.
Version 1 of SNMP is based on passwords in the clear - i.e. the community
name of SNMP PDUs is a password for a manager accessing an agent -. So SNMP
version 1 can be used alone in the first three schemes - local, dedicated
out-of-band, trusted networks management -. To deal with the fourth scheme
it necessary to add to SNMP version 1 a virtual private network service.
Version 2 of SNMP is not yet fully available but should be by the end of
this year as soon as the IETF working group's partners come to an agreement.
SNMPv2 enables user authentication, state-of-the-art message authentication
and ciphering of all PDUs and users' access privileges management.
What are the advantages of SNMP management over other management means for
firewall management ?
SNMP comes with management semantics that no other non-management protocol
offers. These semantics give a unified model for managed features for which
a MIB - Management Information Base - is defined. For private MIBs, SNMP
gives a structure and design rules making MIBs coherent with each other.
The result is an open, comprehensive and coherent management framework.
The main advantages of SNMP firewall management are - some are not
exclusive to SNMP - :
- an SNMP managed firewall is seen as being part of the network as well as
other routers, and its management is coherent with that of routers?;
- there is a very wide choice of graphical user interfaces for every work
station on the market;
- open management using SNMP manager APIs;
- reduced management costs;
- segmented management depending on the role of different security
administrators - e.g. a key master and an authorization manager;
- centralized management of many firewalls;
- alarm on intrusion attempts with redirection to several network managers;
- alarm redirection to pagers - an possible SNMP management station feature;
We want to promote SNMP management of the firewall and want to launch and
participate in a new working group at the IETF to define a standard MIB for
firewall management - not a new version of the SNMP protocol -. This
framework should first define what the main firewall services are and what
services are not firewall services. Then a MIB will be defined for basic
features and so on until most features are dealt with. Compliant firewalls
will conform to parts of the MIB for the services they offer. For services
not already defined, private MIBs may be defined by firewall designers.
For people interested in this work - especially security specialists and
firewall designers -, contact me directly for any suggestions, wishes or
participation in this framework.
Jean Vincent.
---------------------------------------------------------------------
ACTANE Tel : +33 42 93 16 76
Le California Bat D2 Fax : +33 42 93 16 75
2, Rue Jean Andreani Email : jvincent @
actane .
com
13084 Aix-En-Provence CEDEX 2 http://www.actane.com
FRANCE
---------------------------------------------------------------------
|
|
