PETITION FOR INTER PARTES REVIEW OF U.S. PATENT NO. 8,185,964
`
`Exacq Technologies, Inc.
`Exhibit 1005
`
`                        
`
`

`
`United States Patent
`Holloway et al.
`
`[19]
`
`US005905859A
`[11] Patent Number:
`[45] Date of Patent:
`
`5,905,859
`May 18, 1999
`
`[54] MANAGED NETWORK DEVICE SECURITY
`METHOD AND APPARATUS
`
`
`[75] Inventors: Malcolm H_ Holloway, Durham; ~
`OTfhIQImCaS Joseph Pmmck’ Ralelgh’ both
`'
`'
`[73] Assignee: International Business Machines
`Corporation, Armonk, NY.
`
`[21] Appl. NO.Z 08/775,536
`
`5,421,024
`5,440,723
`5,495,580
`
`5/1995 Faulk, Jr. et al. .................... .. 395/800
`8/1995 Arnold et al.
`395/18314
`2/1996 Osman ....... ..
`. 395/187.01
`
`,
`,
`.
`
`lélilangd ............................... .. We .............................. ..
`5,615,340
`395/187.01
`3/1997 Dai etal.
`5,727,146
`3/1998 Savoldi et al. ................... .. 395/187.01
`Primary Examiner—Robert W. Beausoliel, Jr.
`Assistant Examiner—Scott T. Baderman
`Attorney, Agent, or Firm—John J. Timar
`[57]
`ABSTRACT
`
`Jan‘ 9’ 1997
`[22] Flled:
`[51] Int. Cl? .................................................... .. G06F 11/00
`
`An apparatus and method for providing security against
`intrusion in the managed devices of a Campus LAN network
`
`[52] us CL _ _ _ _ _ _ _ _ _ _ _ _ _
`_ _ _ _ _ _ __ 395/187_01
`[58] Field of Search ............................. .. 395/187.01 186
`395/18509, 20053, 20054, 20059, 26055;
`380/3 25
`’
`
`[56]
`
`References Cited
`
`US. PATENT DOCUMENTS
`5/1990 Kravitz et al. .......................... .. 380/23
`1/1993 Schanning et aL
`__ 380/23
`4/1994 Schanning etal.
`.. 380/49
`5/1994 Carmi
`__ 380/23
`8/1994 Faulk, Jr. ..... ..
`.. 370/60
`5/1995 Hershey et al. ...................... .. 395/575
`
`4 930 159
`5j177:788
`5,305,385
`5,311,593
`5,337,309
`5,414,833
`
`is provided. A managed hub discovers each interconnect
`device in the network that Supports the Security feature and
`maintains an interconnect device list of such devices, vvhich
`may include token ring switches, Ethernet switches, bridges
`and routers. The managed hub detects an intrusion by an
`unauthorized address on one of its ports and noti?es the
`interconnect devices of the intrusion by transmitting a
`security breach detected frame. After each interconnect
`device Sets a ?lter on its respective ports against the intrud'
`ing unauthorized address and sends a ?lter set frame to the
`managed huh, the port in the managed huh Where the
`security intrusion occurred is reenabled.
`
`35 Claims, 15 Drawing Sheets
`
`SET PORT #1 IN MANAGED
`HUB TO THE CURRENT PORT
`
`200
`
`THERE AN
`ADDRESS DETECTED
`FOR THE CURRENT
`PORT 7
`
`THE ADDRESS
`ON THE CURRENT PORT IN
`THE LIST OF AUTHORIZED
`ADDRESSES ?
`
`YES
`
`240
`
`SET THE
`CURRENT
`PORT
`NUMBER TO
`THE NEXT
`PORTIN THE
`MANAGED
`HUB
`
`230
`
`NO
`
`THE CURRENT
`PORT THE LAST PORT
`IN THE MANAGED
`HUB?
`
`IS
`THE CURRENT
`PORT ALREADY
`DISABLED ’?
`
`NO
`
`DISABLE THE
`CURRENT PORT
`
`ADD ITEM To THE
`BREACH LIST
`
`260
`
`265
`
`TRANSMIT SECURITY BREACH
`DETECTED FRAME ON ALL
`NETWORK SEGMENTS
`v
`OPTIONALLY TRANSMIT TRAP
`FRAME TO THE NETWORK
`MANAGEMENT STATION
`
`270
`
`280
`
`THIS ATOKEN
`RING NETWORK ?
`
`290
`
`TRANSMIT
`FRAME TO
`THE
`FUNCTIONAL
`ADDRESS OF
`THE LAN
`MANAGER
`295
`
`Exacq
`Ex. 1005
`Page 1
`
`

`
`U.S. Patent
`
`May 18,1999
`
`Sheet 1 0f 15
`
`5,905,859
`
`ER BF:
`
`MANAGEM ENT
`STATION
`
`FDDI RING
`
`MANAGED HUB
`
`28
`
`WORKSTATION
`
`MANAGED HUB
`
`TCP/IP
`SUBNET 1
`
`ROUTER 1
`
`TCP/IP
`SUBNET 3
`
`ROUTER 2
`
`TCP/IP
`SUBNET 4
`
`16
`
`TOKEN RING SWITCH
`
`TOKEN
`RING
`
`- 30
`
`u
`
`I
`
`FILE SERVER
`
`FIG. 1
`
`Exacq
`Ex. 1005
`Page 2
`
`

`
`U.S. Patent
`
`May 18,1999
`
`Sheet 2 of 15
`
`5,905,859
`
`
`
`_>_<mo<_n_good_>_m_._.m.>m88mm_s_m_
`
`
`
`
`
`_>_<m>z_._m<.:
`
` mmmm
`
`n__\n_o._.
`
`._OoO._.OmE
`
`
`
`maoo4<zo:<En_o
`
`E0
`
`mams_Em>m8
`
`
`
`mmmoo<<_om__>_
`
`
`
`n=Io._Om_._.zOo
`
`~.m=m
`
`Exacq
`Ex. 1005
`
`Page 3
`
`
`
`
`
`maoo._.zm_.w<n__>_zm
`
`Exacq
`Ex. 1005
`Page 3
`
`
`
`

`
`U.S. Patent
`
`May 18,1999
`
`Sheet 3 of 15
`
`5,905,859
`
`
`
`
`
`_>_<mo<_oxooazO_._.<._.m._.zm__>_m_0<z<_>_E0252
`
`
`
`
`
`m_m_I._.O
`
`EEE
`
`
`
`
`
`3<$E_mmaV55Eo_>_ms_mommmoomm
`
`mam55$
`
`8
`
`omES._>_oEo8,32%3n_o
`
`m.0_u_
`
`gmm8Mn
`
`m_o<n_m_m_._.z_
`
`
`
`v=.._o>>._.m_zE<om_>mv_
`
`><._%_o
`
`m_o:zos_
`
`Exacq
`Ex. 1005
`
`Page 4
`
`Exacq
`Ex. 1005
`Page 4
`
`
`

`
`U.S. Patent
`
`May 18,1999
`
`Sheet 4 0f 15
`
`5,905,859
`
`ETHERNET 802.3 FORMAT
`
`I DA I
`
`SA I
`
`LENGTH I
`
`LLC DATA I
`
`DATA FIELD I
`
`PAD
`
`I
`
`FCS I
`
`FRAME
`CHECK
`SEQUENCE
`OPTIONAL
`PAD TO 64 BYTES
`
`USER DATA
`—> LOGICAL LINK CONTROL
`
`_’ LENGTH OF THE FRAME
`_’ SOURCE ADDRESS
`
`_”’ DESTINATION ADDRESS
`
`FIG. 4A
`
`ETHERNET VERSION 2 FORMAT
`
`I DA I
`
`SA I TYPE
`
`I
`
`DATA FIELD I
`
`PAD
`I—7
`
`I
`
`FCS I
`I—> FRAME CHECK SEQUENCE
`
`OPTIONAL PAD TO 64 BYTES
`
`USER DATA
`
`—> PROTOCOL IDENTIFIER
`
`"* SOURCE ADDRESS
`
`DESTINATION ADDRESS
`
`FIG. 4B
`
`TOKEN RING FRAME FORMAT
`
`DA
`
`SA
`
`ROUTING
`INFO
`
`LLC DATA
`
`DATA
`FIELD
`
`FCS
`
`L L FRAME CHECK SEQUENCE
`
`USER DATA
`
`LOGICAL LINK CONTROL
`-*LENGTH OF THE FRAME, BRIDGE ID,
`RING ID, HOP COUNT
`—> SOURCE ADDRESS
`DESTINATION ADDRESS
`
`FIG. 4C
`
`Exacq
`Ex. 1005
`Page 5
`
`

`
`U.S. Patent
`
`May 18,1999
`
`Sheet 5 0f 15
`
`5,905,859
`
`DISCOVERY REQUEST
`
`FRAMETYPE TIME STAMP
`IDENTIFIER
`
`1
`
`-
`
`4
`
`BYTES
`
`FIG. 5A
`
`DISCOVERY RESPONSE
`
`FRAMETYPE INTERCONNECT INTERCONNECT TIME STAMP
`IDENTIFIER
`DEVICE MAC
`DEVICE
`
`‘
`
`ADDRESS
`
`_ DESCRIPTION _
`
`1
`
`6
`
`50
`
`4
`
`BYTES
`
`FIG. 55
`
`SECURITY BREACH DETECTED FRAME
`
`DEVICE ADDRESSES
`PORT TIME
`FRAME TYPE INTRUDINC MODULE
`IDENTIFIER
`MAC
`NUMBER NUMBER STAMP FIELD
`
`_ ADDRESS 7
`
`V
`
`7
`
`V LENGTH _
`
`1
`
`e
`
`1
`
`1
`
`4
`
`2
`
`VARIABLE
`LENGTH
`
`BYTES
`
`FIG. 5C
`
`FILTER SET FRAME
`
`FRAMETYPE INTERCONNECT INTRUDINC MODULE PORT TIMESTAMP
`IDENTIFIER
`DEVICE MAC
`MAC
`NUMBER NUMBER
`
`_
`
`ADDRESS ADDRESS
`
`7
`
`v
`
`1
`
`6
`
`6
`
`I
`
`1
`
`4
`
`BYTES
`
`FIG. 5D
`
`SECURITY CLEAR CONDITION
`
`INTRUDING
`FRAME TYPE
`IDENTIFIER MACADDRESS
`
`-
`
`1
`
`6
`
`BYTES
`
`FIG. 5E
`
`Exacq
`Ex. 1005
`Page 6
`
`

`
`U.S. Patent
`
`May 18,1999
`
`Sheet 6 0f 15
`
`5,905,859
`
`INTERCONNECT DEVICE LIST ITEM
`
`MAC ADDRESS DEVICE DESCRIPTION LAST RESPONSE TIME OUTSTANDING BREACH
`RESPONSE COUNT
`
`MAC ADDRESS: MAC ADDRESS OF THE INTERCONNECT DEVICE
`DEVICE DESCRIPTION: ASCII SELF DESCRIPTION PROVIDED BY THE INTERCONNECT DEVICE
`LAST RESPONSE TIME: TIME WHEN LAST RESPONSE RECEIVED FROM INTERCONNECT
`DEVICE
`OUTSTANDING BREACH RESPONSE COUNT: NUMBER OF SECURITY BREACH FRAMES THE
`INTERCONNECT DEVICE HAS NOT RESPONDED
`TO
`
`FIG. 6
`
`BREACH LIST ITEM
`
`MAC ADDRESS BREACH TIME BREACH PORT BREACH MODULE OUTSTANDING FILTER
`SET COUNT
`
`MAC ADDRESS: MAC ADDRESS OF THE INTRUDING DEVICE
`BREACH TIME: TIME WHEN INTRUSION OCCURRED
`BREACH PORT: PORT IN MANAGED HUB WHEN INTRUSION OCCURRED
`BREACH MODULE: MODULE IN MANAGED HUB WHEN INTRUSION OCCURRED
`OUTSTANDING FILTER SET COUNT: NUMBER OF FILTER SET FRAMES NOT RECEIVED YET
`
`FIG. 7
`
`INTRUSION LIST ITEM
`
`MAC ADDRESS BREACH TIME BREACH PORT BREACH MODULE
`
`MAC ADDRESS: MAC ADDRESS OF THE INTRUDING DEVICE
`BREACH TIME: TIME WHEN INTRUSION OCCURRED
`BREACH PORT: PORT IN MANAGED HUB WHEN INTRUSION OCCURRED
`BREACH MODULE: MODULE IN MANAGED HUB WHEN INTRUSION OCCURRED
`
`FIG. 8
`
`Exacq
`Ex. 1005
`Page 7
`
`

`
`U.S. Patent
`
`May 18,1999
`
`Sheet 7 0f 15
`
`5,905,859
`
`100
`
`101
`
`POWER ON / RESET
`I
`
`117
`RECEIVE DISCOVERY
`TIMER INTERRUPT
`
`INTIALIzE SECURITY FEATURE
`
`‘
`
`- LOAD/CLEAR ICD LIST
`- LOAD/CLEAR BREACH LIST
`*GET/SET DISCOVERY PERIOD
`-GET/SET DISC. WINDOW
`-SET INITIALIzED FLAG
`-GET/SET ENABLED FLAG
`
`ICD LIST
`POINTER
`AT END 0|:
`LIST '2
`
`109
`
`No
`
`GET LAST RESPONSE TIME
`FROM ICD LIST ITEM
`
`SECURITY
`FEATURE
`ENABLED ?
`
`H5
`
`110
`
`LAST
`RESPONSE
`T|ME <
`CURRENT
`TIME
`
`103
`
`GFgoclfAug?gggTTrb?E
`
`I
`104
`BUILD DISCOVERY FRAME
`WITH TYPE REQUEST
`
`105
`
`SEND DISCOVERY
`FRAME
`I
`106
`SET DISCOVERY TIMER FOR
`NEXT D|SCOVERY PHASE
`107
`I
`SET IOD LIST POINTER TO
`BEGINNING OF IOD LIST
`
`MOVE POINTER TO
`NExT ICD LIST ITEM
`II
`
`111
`NO
`UPDATE LAST RESPONSE
`TIME IN THE ICD LIST ITEM
`.—_|
`
`112
`
`CURRENT
`TIME - LAST
`RESPONSE TIME
`D'SCOVERY >
`WINDOW
`YES
`
`113
`
`DELETE ITEM FR M
`|CD U81‘ 0
`I
`114
`OPTIONALLY SEND TRAP TO
`NMS CONTAINING ICD LIST ITEM
`INFO
`
`116
`
`RETURN TO 08 IL
`
`FIG. 9
`
`Exacq
`Ex. 1005
`Page 8
`
`

`
`U.S. Patent
`
`May 18, 1999
`
`Sheet 8 0f 15
`
`5,905,859
`
`143
`
`144
`
`RECEIPT OF DISCOVERY
`REQUEST FRAME
`
`SECURITY
`FEATURE
`ENABLED ?
`
`145
`EXTRACT SOURCE INFO
`
`- MAC ADDRESS
`—TIME STAMP
`
`‘I46
`
`II
`
`BUILD DISCOVERY
`RESPONSE FRAME
`
`147
`
`v
`
`SEND FRAME TO HUB
`
`148
`
`RETURN TO 05
`
`FIG. 10
`
`Exacq
`Ex. 1005
`Page 9
`
`

`
`U.S. Patent
`
`May 18, 1999
`
`Sheet 9 0f 15
`
`5,905,859
`
`130
`
`131
`
`RECEIVE DISCOVERY
`RESPONSE FRAME
`I
`EXTRACT ICD INFORMATION
`—MAC ADDRESS
`—DESCRIPTION
`—T|ME STAMP
`
`132
`
`SEARCH ICD LIST FOR
`MATCHING MAC ADDRESS
`
`133
`
`MATCH FOUND ?
`
`134
`UPDATE LAST RESPONSE
`TIME IN ICD LIST ITEM WITH
`EXTRACTED TIME STAMP
`
`II
`
`139
`
`RETURN TO 0S
`
`FIG. 11
`
`DISCOVERY
`WINDOW <
`(CURRENT
`TIME-TIME STAMP)
`* 2 ?
`
`136
`SET DISCOVERY WINDOW
`TO (CURRENT TIME-TIME
`STAMP) * 2
`
`137
`CREATE ICD LIST ITEM
`— MAC ADDRESS
`
`— DESCRIPTION
`— LRT : TIME STAMP
`— COUNT = O
`
`I
`138
`O
`PTIONALLY SEND TRAPS TO
`MS & LNM CONTAINING ICD
`N
`LIST INFO
`
`Exacq
`Ex. 1005
`Page 10
`
`

`
`U.S. Patent
`
`May 18,1999
`
`Sheet 10 0f 15
`
`5,905,859
`
`A
`
`I
`
`SET PORT #1 IN MANAGED
`200 HUB TO THE CURRENT PORT
`
`IS
`THERE AN
`ADDRESS DETECTED
`FOR THE CURRENT
`PORT ?
`
`220
`
`IS
`THE ADDRESS
`ON THE CURRENT PORT IN
`THE LIST OF AUTHORIZED
`ADDRESSES ?
`
`IS
`THE CURRENT
`PORT ALREADY
`DISABLED ?
`
`250
`
`240
`
`SET THE
`CURRENT
`PORT
`NUMBER TO
`THE NEXT
`PORT IN THE
`MANAGED
`HUB
`
`230
`
`NO
`
`THE CURRENT
`PORT THE LAST PORT
`IN THE MANAGED
`HUB ?
`
`265
`
`260
`
`DISABLE THE
`CURRENT PORT
`I
`ADD ITEM TO THE
`BREACH LIST
`I
`TRANSMIT SECURITY BREACH
`DETECTED FRAME ON ALL
`NETWORK SEGMENTS
`I
`OPTIONALLY TRANSMIT TRAP
`FRAME TO THE NETWORK
`MANAGEMENT STATION
`
`270
`
`280
`
`THIS A TOKEN
`RING NETWORK ?
`
`YES
`
`TRANSMIT
`FRAME TO
`THE
`FUNCTIONAL
`ADDRESS OF
`THE LAN
`MANAGER
`295
`
`FIG. 12
`
`Exacq
`Ex. 1005
`Page 11
`
`

`
`U.S. Patent
`
`May 18, 1999
`
`Sheet 11 0f 15
`
`5,905,859
`
`COPY FRAME FROM NETWORK
`AND GET PORT # RECEIVED ON
`
`300
`
`302
`
`306
`
`308
`
`312
`
`316
`
`FRAME DA =
`SECURITY FEATURE
`GROUP
`ADDRESS ‘.7
`
`YES
`GET THE INTRUSION
`IDENTIFIER INFORMATION
`FROM THE FRAME
`
`IS
`THIS INTRUSION
`IN THE INTRUSION
`LIST ?
`
`YES
`
`ADD INTRUSION INFORMATION
`TO THE INTRUSION LIST
`
`<3
`
`SET CURRENT PORT TO PORT #1
`OF THE INTERCONNECT DEVICE
`
`A FILTER FOR
`THE INTRUDING ADDRESS
`ALREADY SET FOR THE
`CURRENT
`PORT ?
`NO
`APPLY A FILTER FOR THE INTRUDING
`ADDRESS ON THE CURRENT PORT
`
`320
`
`SET THE
`CURRENT
`PORT
`NUMBER TO
`THE NEXT
`PORT IN THE
`INTERCONNECT
`DEVICE
`324
`
`NO
`
`THE LAST PORT
`IN THE INTERCON
`NECT DEVICE ?
`
`322
`
`304
`
`RESUME NORMAL
`FRAME PROCESSING
`
`326
`TRANSMIT SECURITY
`BREACH DETECTED
`FRAME ON ALL PORTS
`OTHER THAN THE
`RECEIVED ON PORT
`332
`TRANSMIT FILTER SET
`FRAME TO ORIGINATOR
`OF THE SECURITY
`BREACH DETECTED
`FRAME
`I
`334
`OPTIONALLY SEND TRAP
`FRAME TO NETWORK
`MANAGEMENT STATION
`
`THIS A TOKEN YES
`
`338
`TRANSMIT
`FRAME TO
`THE
`FUNCTIONAL
`ADDRESS OF
`THE LAN
`MANAGER
`
`RESUME PROCESSING
`AT STEP 300
`
`340
`
`FIG. 13
`
`Exacq
`Ex. 1005
`Page 12
`
`

`
`U.S. Patent
`
`May 18,1999
`
`Sheet 12 0f 15
`
`5,905,859
`
`400
`
`401
`
`402
`
`RECEIvE FILTER SET FRAME
`I
`GET FRAME SA
`I
`sCAN ICD LIST FOR FRAME
`souRCE MAC ADDRESS
`
`40s
`
`ICD MAC ADDRESS
`FOUND ?
`
`404
`
`405
`
`406
`
`DECREMENT OUTSTANDING
`BREACH REsPoNsE COUNT IN
`ICD LIST ITEM BY 1
`‘<—-—-——_
`ExACT INFO FRoM INTRusIoN
`IDENTIFIER INFO IN FRAME
`-INTRuDER MAC ADDRESS
`I
`SCAN BREACH LIST FoR BREACH
`LIST ITEM MATCHING MAC
`ADDRESS
`
`407
`
`MATCH FOUND ?
`
`NO
`
`408
`
`BECREMENTouTsTANDINC
`FILTER sET COUNT BY 1
`
`409
`
`BREACH
`LIST ITEM
`OUTSTANDING
`FILTER SET COUNT
`==O ?
`
`NO
`
`YES
`
`410
`
`411
`
`412
`
`REMOVE ITEM FROM BREACH LIST
`Y
`OPTIONALLY SEND TRAPS TO NMS
`Y
`OPTIONALLY REENABLE BREACHED PORT
`I
`
`413 I
`
`RETuRN TO 05
`
`I
`
`FIG. 14
`
`Exacq
`Ex. 1005
`Page 13
`
`

`
`U.S. Patent
`
`May 18,1999
`
`Sheet 13 0f 15
`
`5,905,859
`
`500
`
`RECEIVE SECURITY CLEAR
`CONDITION FRAME
`
`501
`
`502
`
`503
`
`504
`
`I
`
`EXTRACT INTRuDER MAC
`ADDRESS FRoM FRAME
`I
`SCAN INTRUSION LIST FCR
`MATCHING MAC ADDRESS
`
`MATCH FOUND ?
`
`REMovE ITEM FRCM
`INTRUSION LIST
`
`V
`
`505
`
`REMovE FILTER FoR
`INTRUDING MAC ADDRESS
`
`506
`
`( RETURN TO OS )
`
`FIG. 15
`
`Exacq
`Ex. 1005
`Page 14
`
`

`
`U.S. Patent
`
`May 18, 1999
`
`Sheet 14 0f 15
`
`5,905,859
`
`NETWORK
`MANAGE NT
`STA
`
`ROUTER
`
`A
`
`4I—— CAMPUS BACKBONE
`A
`
`A
`
`SWITCH 1
`l1: mu
`ADMINISTRATION A
`
`BUILDING
`
`B _
`
`In ml] SWITCH 2
`
`@
`
`DORMITORY
`
`FLOOR 4
`
`@
`
`FLOOR 4
`ADMINISTRATION
`
`m
`MANAGED HUB
`FLOOR 3 @
`
`FINANCE
`I
`MANAGED HUB
`
`A A
`A @
`A
`
`MANAGED HUB
`
`FLOOR 3
`
`l
`MANAGED HUB
`
`FLOOR 2
`
`PERSONNEL
`I
`MANAGED HUB
`
`FLOOR 1
`
`PAYROLL
`I
`MANAGED HUB
`
`@ INTERCONNECT DEVICES
`
`FIG. 16
`
`FLOOR 2
`
`@
`MANAGED HUB
`
`FLOOR 1
`
`MANAGED HUB E
`
`@
`
`RUN
`KST
`
`N
`
`Exacq
`Ex. 1005
`Page 15
`
`

`
`U.S. Patent
`
`May 18,1999
`
`Sheet 15 0f 15
`
`5,905,859
`
`mmgom
`
`Exacq
`Ex. 1005
`Page 16
`
`

`
`1
`MANAGED NETWORK DEVICE SECURITY
`METHOD AND APPARATUS
`
`Reference to Related Application
`
`This application is related to the following application
`having the same assignee and inventorship and containing
`common disclosure, and is believed to have an identical
`effective ?ling date: “System and Method for Detecting and
`Preventing Security Intrusions in Campus LAN Networks”,
`Ser. No. 08/780804.
`
`BACKGROUND OF THE INVENTION
`
`This invention relates in general to computer network
`security systems and in particular to systems and methods
`for detecting and preventing intrusion into a campus local
`area network by an unauthoriZed user.
`As local area networks (LANS) continue to proliferate,
`and the number of personal computers (PCs) connected to
`LANs continue to grow at a rapid pace, network security
`becomes an ever increasing problem for network adminis
`trators. As the trend of deploying distributed LANs
`continues, this provides multiple access points to an enter
`prise’s network. Each of these distributed access points, if
`not controlled, is a potential security risk to the network.
`To further illustrate the demand for improved network
`security, an IDC report on network management, “LAN
`Management: The Pivotal Role of Intelligent Hubs”, pub
`lished in 1993, highlighted the importance of network secu
`rity to LAN administrators. When asked the importance of
`improving management of speci?c LAN devices, 75% of the
`respondents stated network security is very important. When
`further asked about the growing importance of network
`security over the neXt three years, many respondents indi
`cated that it would increase in importance.
`More recently, a request for proposal from the US.
`Federal Reserve speci?ed a requirement that a LAN hub
`must detect an unauthoriZed station at the port level and
`disable the port within a 10-second period. Although this
`requirement will stop an intruder, there is an inherent
`weakness in this solution in that it only isolates the security
`intrusion to the port of entry. The rest of the campus network
`is unaware of an attempted break-in. The detection of the
`unauthoriZed station and the disabling of the port is the ?rst
`reaction to a security intrusion, but many signi?cant
`enhancements can be made to provide a network-wide
`security mechanism. Where the above solution stops at the
`hub/port level, this invention provides signi?cant enhance
`ments to solving the problem of network security by pre
`senting a system wide solution to detecting and preventing
`security intrusions in a campus LAN environment.
`In today’s environment, network administrators focus
`their attention on router management, hub management,
`server management, and switch management, with the goals
`of ensuring network up time and managing growth (capacity
`planning). Security is often an afterthought and at best
`administrators get security as a by-product of employing
`other device functions. For example, network administrators
`may set ?lters at router, switch, or bridge ports for perfor
`mance improvements and implicitly realiZe some level of
`security as a side effect since the ?lters control the How of
`frames to LAN segments.
`The problem with using ?lters is that their primary focus
`is on performance improvements, by restricting the How of
`certain types of network traf?c to speci?ed LAN segments.
`The ?lters do not indicate how many times the ?lter has
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`5,905,859
`
`2
`actually been used and do not indicate a list of the media
`access control (MAC) addresses that have been ?ltered.
`Therefore, ?lters do not provide an adequate detection
`mechanism against break-in attempts.
`Another security technique that is commonly employed in
`hubs is intrusion control. There are token ring and Ethernet
`managed hubs that allow a network administrator to de?ne,
`by MAC address, one or more authoriZed users per hub port.
`If an unauthoriZed MAC address is detected at the hub port,
`then the port is automatically disabled. The problem with
`this solution is that prevention stops at the hub and no further
`action is taken once the security intrusion has been detected.
`This solution does not provide a network-centric, system
`wide solution. It only provides a piecemeal solution for a
`particular type of network hardware namely, the token ring
`and Ethernet managed hubs. The result is a fragmented
`solution, where security may eXist for some work groups
`that have managed hubs installed, but not for the entire
`campus network. At best, the security detection/prevention
`is localiZed to the hub level and no solution exists for a
`network-wide solution.
`Other attempts to control LAN access have been done
`with software program products. For eXample, IBM Corpo
`ration’s Lan Network Management (LNM) products LNM
`for OS2 and LNM for AIX both provide functions called
`access control to token ring LANs. There are several prob
`lems with these solutions. One problem with both of these
`solutions is that it takes a long time to detect that an
`unauthoriZed station has inserted into the ring. An intruder
`could have ample time to compromise the integrity of a LAN
`segment before LNM could take an appropriate action.
`Another problem with the LNM products is that once an
`unauthorized MAC address has been detected, LNM issues
`a remove ring station MAC frame. Although this MAC
`frame removes the station from the ring, it does not prevent
`the station from reinserting into the ring and potentially
`causing more damage. Because these products do not pro
`vide foolproof solutions, and signi?cant security eXposure
`still eXists, they do not provide a viable solution to the
`problem of network security for campus LAN environments.
`Thus, there is a need for a mechanism in the managed
`devices of a computer network that enables a comprehensive
`solution and that not only provides for detection of security
`intrusions, but also provides the proactive actions needed to
`stop the proliferation of security intrusions over the domain
`of an entire campus network.
`
`SUMMARY OF THE INVENTION
`
`It is, therefore, an object of the invention to provide an
`apparatus and method in a managed device for detecting and
`preventing security intrusions in a computer network.
`It is another object of the invention to provide an appa
`ratus and method in a managed hub for detecting and
`preventing security intrusions in a computer network.
`Overall, this invention can be described in terms of the
`following procedures or phases: discovery, detection,
`prevention, hub enable, and security clear. During each of
`these phases, a series of frames are transmitted between the
`interconnect devices on a campus network. These frames are
`addressed to a group address (multicast address). This well
`known group address needs to be de?ned and reserved for
`the LAN security functions that are described herein. This
`group address will be referred to as LAN security feature
`group address throughout the rest of this description.
`The campus LAN security feature relies on managed hubs
`discovering the interconnect devices in the campus LAN
`
`Exacq
`Ex. 1005
`Page 17
`
`

`
`5,905,859
`
`3
`segment that support this LAN security feature. The term
`“LAN interconnect device” is used throughout this descrip
`tion to refer to LAN sWitches (token ring and Ethernet
`10/100 Mbps), LAN bridges and routers. The managed hub
`maintains a list of authoriZed MAC addresses for each port
`in the managed hub. If the managed hub detects an unau
`thoriZed station connecting to the LAN, the hub disables the
`port and then transmits a security breach detected frame to
`the LAN security feature group address. Each of the LAN
`interconnect devices on the campus LAN segment copies the
`LAN security feature group address and performs the fol
`loWing steps: 1) set up ?lters to ?lter the intruding MAC
`address; 2) forWard the LAN security feature group address
`to other segments attached to the LAN interconnect device;
`and 3) send an acknowledgement back to the managed hub
`indicating that the intruding address has been ?ltered at the
`LAN interconnect device. Once the managed hub receives
`acknowledgements from all of the interconnect devices in
`the campus LAN, the port Where the security intrusion Was
`detected is re-enabled for use. Another part of the invention
`provides a netWork management station With the capability
`to override any security ?lter that Was set in the above
`process.
`The folloWing is a brief description of each phase in the
`preferred embodiment of the invention:
`1. Discovery
`In this phase, the managed hub determines the intercon
`nect devices in the campus netWork that are capable of
`supporting the LAN security feature. The managed hub
`periodically sends a discovery frame to the LAN security
`feature group address. The managed hub then uses the
`responses to build and maintain a table of interconnect
`devices in the netWork that support the security feature.
`2. Detection
`In the detection phase, the managed hub compares the
`MAC addresses on each port against a list of authoriZed
`MAC addresses. If an unauthoriZed MAC address is
`detected, then the managed hub disables the port and noti?es
`the other interconnect devices in the campus netWork by
`transmitting a security breach detected frame to the LAN
`security feature group address.
`40
`3. Prevention
`The prevention phase is initiated When a LAN intercon
`nect device receives the security breach detected frame.
`Once this frame is received, the LAN interconnect device
`45
`sets up a ?lter to prevent frames With the intruding MAC
`address from ?oWing through this netWork device. The LAN
`interconnect device then forWards the security breach
`detected frame to the other LAN segments attached to the
`interconnect device. The LAN interconnect device also
`transmits a ?lter set frame back to the managed hub.
`4. Hub Enable
`The hub enable phase takes place When the managed hub
`has received all acknoWledgements from the LAN intercon
`nect devices in the campus netWork. When the acknoWl
`edgements have been received, the managed hub re-enables
`the port Where the security intrusion occurred.
`5. Security Clear Condition
`In this phase, a netWork management station can remove
`a ?lter from a LAN interconnect device that Was previously
`set in the prevention step.
`
`4
`FIG. 2 is a component block diagram for an SNMP
`managed device.
`FIG. 3 is a component block diagram for a netWork
`management station.
`FIGS. 4A—4C shoW general frame formats for Ethernet
`and token ring frames.
`FIGS. 5A—5E shoW the information contained in the
`Ethernet and token ring frame data ?elds to represent the
`different frame types that are implemented in the preferred
`embodiment.
`FIG. 6 illustrates the structure of the Interconnect Device
`List (ICD).
`FIG. 7 illustrates the structure of the Breach List.
`FIG. 8 illustrates the structure of the Intrusion List.
`FIG. 9 is a How chart of the processing that occurs in the
`managed hub to initiate the discovery phase of the invention.
`FIG. 10 is a How chart of the processing that occurs in the
`interconnect device during the discovery phase of the inven
`tion.
`FIG. 11 is a How chart of the processing that occurs in the
`managed hub during the discovery phase of the invention in
`response to the receipt of a discovery response frame.
`FIG. 12 is a How chart of the processing that occurs in the
`managed hub during the detection phase of the invention.
`FIG. 13 is a How chart of the processing that occurs in an
`interconnect device during the prevention phase of this
`invention.
`FIG. 14 is a How chart of the processing that occurs in the
`managed hub during the hub enable phase of the invention.
`FIG. 15 is a How chart of the processing that occurs in the
`interconnect devices in response to the receipt of a security
`clear condition frame.
`FIG. 16 is an eXample of the implementation of the
`invention in a campus LAN environment.
`FIG. 17 is an eXample of the data ?oWs corresponding to
`the eXample implementation in a campus LAN environment.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENT
`
`The preferred embodiment of this invention uses the
`SNMP netWork management protocol, since SNMP is the
`most prevalent netWork management protocol in the indus
`try and is the most Widely deployed in campus netWorks. It
`should be noted that the concepts in this invention related to
`netWork management could also be applied to other netWork
`management protocols such as CMIP or SNA.
`FIG. 1 illustrates a typical campus netWork environment
`in Which the present invention can be implemented. As
`shoWn in the ?gure, the campus netWork 10 contains inter
`connect devices, such as router 12, router 14, token ring
`sWitch 16, bridge 18, managed hubs 20, 22, 24, netWork
`management station 26, Workstation 28 and ?le server 30.
`The managed hubs and interconnect devices depicted in
`FIG. 1 are considered SNMP managed devices. The typical
`component block diagram for an SNMP managed device is
`illustrated in FIG. 2. Atypical managed device is an embed
`ded system that includes a system bus 50, random access
`memory (RAM) 52, NVRAM 54 to store con?guration
`information, FLASH EPROM 56 to store the operational
`and boot-up code, a processor or CPU 58 to eXecute the code
`instructions, and a media access control (MAC) chip 66 that
`connects the device to the netWork 10. FIG. 2 also shoWs
`operational code 60, TCP/IP protocol stack 62 and SNMP
`agent code 64. In most instances, the operational code and
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`50
`
`55
`
`60
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`The invention Will be described With respect to a preferred
`embodiment thereof Which is further illustrated and
`described in the draWings.
`FIG. 1 is a block diagram of a campus netWork in Which
`the present invention can be implemented.
`
`65
`
`Exacq
`Ex. 1005
`Page 18
`
`

`
`15
`
`25
`
`35
`
`5
`the frame processing code execute in FLASH memory 56 or
`in RAM 52. The code that implements several phases in this
`invention is included as a part of the operational code
`(microcode or ?rmWare) of the managed device. The MAC
`chip 66 copies the frames corresponding to the different
`phases into RAM 52 and noti?es the processor 58, usually
`via an interrupt, that a frame is ready for processing. The
`operational code 60 handles the interrupt and processes the
`frame.
`FIG. 3 illustrates the typical component block diagram for
`a netWork management station such as that indicated by
`reference numeral 26 in FIG. 1. The netWork management
`station includes a processor 70, With a system bus 90 to
`Which RAM 72, direct access storage device (DASD) 74,
`other peripherals 76, display monitor 78, keyboard 80,
`mouse 82 and netWork interface card 84 are connected.
`FIGS. 4A—4C shoW the general frame formats for Ether
`net and token ring frames. The LAN security feature group
`address is placed in the destination address (DA) ?eld of the
`discovery request, security breach detected and security
`clear condition (optionally) frames as discussed more fully
`beloW. The data ?eld portion of each frame is used to pass
`the additional information related to this security feature.
`The folloWing describes the information that is included
`in the data ?elds of the Ethernet and token ring frame types
`to represent the different frames that are speci?c to the
`preferred embodiment of the invention.
`The discovery request frame shoWn in FIG. 5A is sent to
`the LAN security feature group address and the data ?eld
`includes a one byte ?eld Which indicates that the frame type
`(frame type identi?er X ‘01’) is a discovery request frame.
`The time stamp ?eld is the system time value When the
`discovery request frame is transmitted. It is used to correlate
`the discovery response frame With the discovery request
`frame.
`The discovery response frame shoWn in FIG. 5B is sent to
`the individual MAC address of the managed hub that
`initiated the request. The data ?eld in this frame includes a
`one byte ?eld Which indicates that the frame type is a
`discovery response frame (frame type identi?er X ‘02’), and
`also contains the MAC address of the LAN interconnect
`device sending the frame, a description of the LAN inter
`connect device (e.g., IBM 8272 Model 108 Token Ring
`SWitch), and a time stamp that is used to correlate the
`discovery response frame With the discovery request frame.
`The security breach detected frame shoWn in FIG. 5C is
`sent to the LAN security feature group address and the data
`?eld includes a one byte ?eld Which indicates that the frame
`type is a security breach detected frame (frame type iden
`ti?er X ‘03’) and contains the MAC address that Was
`detected as the security intruder. Other ?elds of this frame
`contain the module number and port number Where the
`security breach Was detected and the system time When the
`security breach Was detected. When the time stamp value is
`used in combination With the intruding MAC address and
`module and port numbers, it forms an intrusion identi?er as
`Will be referred to subsequently. FolloWing the time stamp
`are device ?eld length indicating the length of the ?eld that
`folloWs and address ?elds. The address ?eld contains the list
`of addresses that have processed and forWarded the security
`breach detected frame. It starts With the originating MAC
`address of the managed hub. Each successive interconnect
`device that receives the frame, appends its MAC address to
`the end of this ?eld and updates the device ?eld length
`before it forWards the frame. It provides an audit trail or path
`that the security breach detected frame folloWed throughout
`
`45
`
`55
`
`65
`
`5,905,859
`
`6
`the netWork. AnetWork management station can monitor the
`progress of the security breach detected frame through
`information in the trap frames that it receives.
`The ?lter set frame shoWn in FIG. 5D is sent to the
`individual MAC address of the managed hub that initiated
`the security intrusion condition. The data ?eld includes a one
`byte ?eld Which indicates that the frame type is a ?lt er set
`frame (frame type identi?er X ‘04’) and contains the MAC
`address of the LAN interconnect device sending the frame.
`Other ?elds in this frame are the MAC address of the
`detected intrusion, the module and port number of the
`managed hub Where the security intrusion Was detected, and
`the time stamp representing the system time When the
`security breach Was detected.
`The security clear condition frame shoWn in FIG. 5E can
`be sent to the LAN security feature group address or to the
`individual MAC address of a LAN interconnect device. The
`data ?eld includes a one byte ?eld Which indicates that the
`frame type is a security clear condition frame (frame type
`identi?er X ‘05’) and contains the intruding MAC address to
`remove as a ?lter.
`Trap frames are sent to the netWork management station
`at various times depending upon the phase of the invention
`that is being performed. All trap frames have the same basic
`format With the information in each trap frame varying
`according to the phase.
`In the discovery phase, traps are sent as a result of the
`managed hub deleting an interconnect device from the list of
`devices that are in the security domain of interconnect
`devices. The discovery trap frame contains the trap identi?er
`(X ‘01’), the MAC address of the interconnect device and
`device description. This trap indicates that an interconnect
`device Was removed from a managed hub interconnect
`device list because it did not respond to