----- Forwarded message from Thomas Schmidt <[EMAIL PROTECTED]> -----
Message-ID: <[EMAIL PROTECTED]>
From: Thomas Schmidt <[EMAIL PROTECTED]>
Reply-To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>,
"'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
Cc: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>,
"'[EMAIL PROTECTED]'"
<[EMAIL PROTECTED]>
Subject: RE: TESO advisory - BinTec router
Date: Tue, 11 Apr 2000 12:08:01 +0200
Organization: BinTec Communications AG
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Concerning a Security Advisory called "BinTec ISDN router
family issues" recently published at http://teso.scene.at/ as
"TESO Security Advisory 9" (Author: Stephan Holtwisch)
BinTec as the router manufacturer want?s to make the
following statement:
The following points were mentioned in this Security Advisor
as vulnerabilites of a BinTec Router.
> 1. By using SNMP brute-force-techniques for SNMP community-names
> one is able to gain the management accounts passwords, which are
> the same as the SNMP community names.
> 2. Additionally the MIB-Tree holds security related information
> which should not be accessible through read-only/SNMP.
> 2. These routers also offer services which can be abused rather
> easily, like dialing out and getting full line access via a CAPI
> interface, or a debugging interface which gives you all
information
> which is sent over the BRI-lines.(Those services are open as
default
> and the debugging service is barely documented)
1. Detecting and defending SNMP-Brute Force Access
Scanning the management account passwords of a Bintec Router with
a brute force attack via SNMP access can be detected and prevented
in the following ways:
Detection:
Every system access with an invalid management account
password is detected by the router and logged (local, via
console and via syslog to one or more external hosts).
In addition to that, SNMP requests with illegal community
passwords cause an SNMP Trap.
Defense:
We recommend using one or more of the following three methods
to deny SNMP access from untrusted WAN interfaces or to
restrict SNMP access to trusted IP addresses.
a) Use of Network Address Translation.
The use of NAT will allow outgoing connections but deny any
incoming connections from hosts on the other side of the
WAN interface. This is also the default configuration for internet
access, when the Bintec Router is configured via the Wizard.
Bintec routers also can offer a special NAT mode without
Address Translation, i.e. packets traveling through the router
are not modified but connections from outside are still denied.
b) Use of Access Lists
Filters and access lists can be defined for every interface.
They can be used to grant access to local services via
trusted IP addresses and/or trusted interfaces only, and
deny the access to all others.
c) Use of "Local Service" Access Lists
There are also two SNMP tables on the system to specify
the trusted IP addresses to connect to any local service
(localtcpallowtable and localudpallowtable). These tables
are easier to handle and set up than access lists.
Beginning with release 5.2.1, this configuration will
be accessible via the built-in SETUP-Tool.
2. Defending SNMP Access to security related information
To defend SNMP-Access to security related information in
the private MIBs, the SNMP access has to be restricted.
Again we recommend using one or more of the three methods
mentioned in section 1a) to 1c)
3. Detecting and Defending abuse of other local services
The abuse of other local services like CAPI, TAPI and TRACE
can be detected and prevented in the following ways:
Detection:
Every CAPI, TAPI and trace connection is detected and
logged (local, via console and via syslog to one or more
external hosts). The syslog includes timestap,
source IP address/port and type of service.
If connections are established or accepted via CAPI
and/or TAPI, the timestamp, duration, number, charging
information are logged together with source IP address
of the TAPI/CAPI-user.
Defense:
We recommend using one or more of the following three methods
mentioned in section 1a) to 1c) to defend CAPI/TAPI or
TRACE access from untrusted WAN interfaces or to restrict
the access to trusted IP addresses.
References
=========
[1] BinTec Communications
http://www.bintec.de
[2] User Documentation on "Access Security"
http://www.bintec.de/download/brick/doku/70000b.pdf german, pg. 248
http://www.bintec.de/download/brick/doku/71000b.pdf english, pg. 240
(includes description of all methods mentioned above)
The printed version of the user manual is delivered
with every Bintec router.
[3] Additional Documentation of "NAT"
http://www.bintec.de/download/brick/doku/71040a.pdf english, pg. 282
[4] Additional Documentation of "Access lists"
http://www.bintec.de/download/brick/doku/71040a.pdf english, pg. 277
[5] Additional Documentation of "Local Access lists"
http://www.bintec.de/download/brick/doku/RN_XL482.pdf english, pg.
10
[6] TESO
http://teso.scene.at/ or https://teso.scene.at/
[7] Stephan Holtwisch
[EMAIL PROTECTED]
# Thomas Schmidt - Productlinemanager
# BinTec Communications AG
# Suedwestpark 94 , 90449 Nuernberg
# Phone: +49-911-9673-0 , Fax: +49-911-6880725
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.0.2i
iQA/AwUBOPLrU1uDFIQcc8vNEQKZ2gCfWLewpO3bQQf6hIEOpQfbvmtZDmsAoO0M
7PtfiocOVpdDGkU5ro6VXRtk
=MpNz
-----END PGP SIGNATURE-----
----- End forwarded message -----
--
Elias Levy
SecurityFocus.com
http://www.securityfocus.com/
