Foundry Networks Security Advisories Archive (bugTraq)

01 /The bugTraq.html page and why it was linked

Foundry published its security notices on a single page at the root of the corporate site, named bugTraq.html after the disclosure mailing list of the era. The page listed each advisory with the affected products, the IronWare releases that fixed it and sometimes a link to a longer response document. Vulnerability databases and mailing-list archives linked to it as the vendor statement, which made it one of the most externally linked URLs on the domain. After the Brocade integration the page disappeared and those citations broke. This page records what was there in general terms and does not reproduce the notices.

02 /February 2002: multi-vendor SNMP vulnerabilities (CA-2002-03)

In February 2002 the CERT Coordination Center published advisory CA-2002-03 after the Oulu University Secure Programming Group (OUSPG) released its PROTOS test suite of malformed SNMPv1 messages. Nearly every network vendor was affected, Foundry among them, because IronWare shipped an SNMP agent listening by default. Foundry issued fixed IronWare releases and advised filtering UDP 161 and 162 at the network edge in the meantime. The SNMP MIBs page covers the protocol side.

03 /September 2003: OpenSSH buffer management (CA-2003-24)

CERT advisory CA-2003-24 of September 2003 described a buffer management error in OpenSSH releases before 3.7. Embedded devices whose SSH servers derived from that code were exposed, and Foundry published a notice for the IronWare SSH implementation under /solutions/advisories/. The fix was an IronWare update; the interim mitigation was an access list limiting which hosts could open TCP 22 to the device.

04 /April 2004: TCP reset attacks (NISCC 236929)

In April 2004 the UK NISCC published advisory 236929. It showed that a spoofed TCP RST or SYN segment only needed a sequence number inside the receive window, not an exact match, to tear down a connection, and that long-lived BGP sessions between routers were the natural target. Foundry, whose NetIron routers ran BGP in service provider cores, published a TCP vulnerability response document listing affected releases and mitigations: TCP MD5 signatures on BGP sessions (RFC 2385) and ingress filtering of spoofed sources.

05 /Other advisory classes of the era

• Default SNMP community strings. Early IronWare shipped with the read-only community public and, on some releases, a read-write community, giving configuration access to anyone on the management network.
• Telnet exposure. Telnet was on by default and carried credentials in clear text; several notices concerned telnet authentication behaviour on specific releases.
• Web management interface. The HTTP interface had authentication and input handling bugs common to every vendor of the period.

06 /Hardening a legacy IronWare device today

No vendor issues fixes for Foundry-era IronWare. The only controls left are exposure and configuration. The list below is the minimum.

1. Put the management IP on a dedicated management VLAN (VLANs) not routed to the internet or to user segments.
2. Disable telnet and the HTTP management interface. Use SSH version 2 only and regenerate the host key so a previous owner does not hold it.
3. Disable SNMP unless polling is needed. If it is, use SNMPv3 where the release supports it, otherwise a long random read-only community restricted by ACL. Never enable a read-write community.
4. Apply access lists to every management service so only the monitoring host and the admin jump host can reach the device.
5. Change every password, remove unknown user accounts, and do not expose any service to the internet.

configure terminal
no telnet server
no web-management http
crypto key generate rsa
access-list 10 permit host 10.10.0.5
ssh access-group 10
no snmp-server community public ro
snmp-server community LONG-RANDOM-STRING ro 10
enable super-user-password NEW-PASSWORD
write memory

Exact keywords vary between IronWare releases and between switch and router images; see the CLI reference. Verify from outside with a port scan of the management address: only TCP 22, and UDP 161 if SNMP is required, should answer. Unknown credentials are handled under password recovery.