(12) United States Patent
`Rowland
`
`USOO6405318B1
`(10) Patent No.:
`US 6,405,318 B1
`(45) Date of Patent:
`Jun. 11, 2002
`
`(54) INTRUSION DETECTION SYSTEM
`
`(75) Inventor: Craig H. Rowland, Austin, TX (US)
`
`3/2000 Dutcher et al. ............. 713/200
`6,044,465. A
`6,070,244. A * 5/2000 Orchier et al. .............. 713/201
`6,073,240 A * 6/2000 Kurtzberg - - - - - - - - - - - - - - - - - - - 713/200
`
`(73) Assignee: Psionic Software, Inc., Austin, TX
`(US)
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`
`(*) Notice:
`
`* cited by examiner
`Primary Examiner-Gail Hayes
`Assistant Examiner Jeff Leaniny
`(74) Attorney, Agent, or Firm Taylor Russell & Russell,
`P.C.
`
`(21) Appl. No.: 09/268,084
`(22) Filed:
`Mar 12, 1999
`9
`(51) Int. Cl. ................................................. G06F 11/30
`(52) U.S. Cl. ....................................................... 713/200
`(58) Field of Search ................................. 713/200, 164;
`709/229
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`5,278.901 A
`1/1994 Shieh et al. ................... 380/4
`5,365,581. A 11/1994 Baker et al. ................ 379/196
`5,495,521 A * 2/1996 Rangacher ................... 379/95
`5,557,742 A
`9/1996 Smaha et al. ............... 395/186
`5,621,889 A 4/1997 Lermuzeaux et al. ....... 395/186
`5,623,601. A
`4/1997 Vu ........................ 395/187.01
`5,796,942 A 8/1998 Esbensen ............... 395/187.01
`5,798,706 A
`8/1998 Kraemer et al. ....... 340/825.07
`5,825,750 A * 10/1998 Thompson .................. 370/244
`5.991,881. A * 11/1999 Conklin ........
`... 713/201
`6,014,715. A
`1/2000 Stoevhase .................... 710/11
`
`ABSTRACT
`(57)
`A computer-implemented intrusion detection System and
`method that monitors a computer System in real-time for
`activity indicative of attempted or actual access by unau
`thorized persons or computers. The System detects unautho
`rized users attempting to enter into a computer System by
`comparing user behavior to a user profile, detects events that
`indicate an unauthorized entry into the computer System,
`notifies a control function about the unauthorized users and
`events that indicate unauthorized entry into the computer
`System and has a control function that automatically takes
`action in response to the event. The user profiles are dynami
`cally constructed for each computer user when the computer
`user first attempts to log into the computer System and upon
`Subsequent logins, the user's profile is dynamically updated.
`By comparing user behavior to the dynamically built user
`profile, false alarms are reduced. The System also includes a
`log auditing function, a port Scan detector and a Session
`monitor function.
`
`31 Claims, 11 Drawing Sheets
`
`
`
`
`
`OGN ANOMALY
`DETECTOR
`
`LOGOUT ANOMALY
`DETECTOR
`
`SESSION
`MONITOR
`
`
`
`
`
`
`
`LOG
`AUDITING
`
`2
`
`CONTROLLER
`
`PORT SCAN
`DETECTOR
`
`6
`NTRUSION DETECTION SYSTEM
`
`5
`
`N
`
`ZSCALER Ex. 1025 p.1
`
`

`

`U.S. Patent
`
`Jun. 11, 2002
`
`Sheet 1 of 11
`
`US 6,405,318 B1
`
`NOISSAS
`
`YOLINOW
`
`
`
`AIVWONVLNOSO)
`
`
`
`AIWWONVNISO7
`
`YOLOS1AG
`
`YOLOsLAd
`
`
`
`
`
`NVOSLdYOd
`
`YOLOS14d
`
`YATIOULNOO
`
`J01
`
`ONILIGAV
`
`9
`
`G
`
`
`
`
`
`WALSASNOIWOSL3dNOISNYLNI
`
`T—-J1d4
`
`ZSCALER Ex. 1025 p.2
`ZSCALER Ex. 1025 p.2
`
`
`
`

`

`U.S. Patent
`
`Jun. 11, 2002
`
`Sheet 2 of 11
`
`US 6,405,318 B1
`
`I ?
`
`I I
`
`
`
`
`
`NWONX
`
`0 I
`
`IE>JONO| O | S | NEAE
`
`f7 I
`
`9 I
`
`NWONXANO
`
`2. I
`
`GI
`
`ZSCALER Ex. 1025 p.3
`
`

`

`U.S. Patent
`
`Jun. 11, 2002
`
`Sheet 3 of 11
`
`US 6,405,318 B1
`
`LOGIN ANOMALY DETECTOR
`
`MONITOR SYSTEM LOGIN/LOGOUT
`AUDIT FILES
`
`2O
`
`21
`
`YES
`
`
`
`SHOULD
`USER BE
`GNORED2
`
`38
`
`FIG-3
`
`BUILD/DYNAMICALLY UPDATE USER
`PROFILE (GO TO FIG-4)
`
`22
`
`27
`
`
`
`
`
`FOREIGN
`DOMAN
`LOGINT
`
`FOREIGN
`DOMAN
`ALLOWED P
`
`NO
`
`MULTIPLE
`LOGNS
`ALLOWED2
`
`ODD LOGIN
`TIMEST
`
`KNOWN
`ATTACK
`PATTERN2
`
`NO
`
`LOGN USER
`
`37
`
`35
`
`NOTIFY CONTROL
`FUNCTION
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`ZSCALER Ex. 1025 p.4
`
`

`

`U.S. Patent
`
`Jun. 11, 2002
`
`Sheet 4 of 11
`
`US 6,405,318 B1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`ZSCALER Ex. 1025 p.5
`
`

`

`U.S. Patent
`
`Jun. 11, 2002
`
`Sheet S of 11
`
`US 6,405,318 B1
`
`LOGOUT ANOMALY DETECTOR
`
`DYNAMICALLY UPDATE USER PROFILE AND
`ACTIVE USER DATABASE FOR LOGOUT
`
`
`
`YES
`
`
`
`
`
`SHOULD
`USER BE
`GNORED2
`
`65
`
`49
`
`50
`
`52
`
`YES
`
`51
`
`
`
`
`
`
`
`HISTORY
`FILE
`COMPROMISED P
`
`
`
`56
`
`
`
`HOST FILE
`HAS
`DANGEROUS
`MODIFICATION?
`
`HISTORY FILE
`TRUNCATED2
`
`HISTORY FILE
`SYMBOLC
`LINK?
`
`
`
`
`
`
`
`59
`
`
`
`
`
`
`
`HOME
`DIRECTORY HAS
`SUSPCOUS
`MODIFICATION?
`
`
`
`SAME AS
`KNOWN
`SUSPCOUS
`DIRECTORY?
`
`
`
`FIG-5A
`
`ZSCALER Ex. 1025 p.6
`
`

`

`U.S. Patent
`
`Jun. 11, 2002
`
`Sheet 6 of 11
`
`US 6,405,318 B1
`
`63
`
`NETWORK
`PROCESS
`ACTIVE AFTER
`LOGOUT2
`
`
`
`ALTERED OR
`
`
`
`
`
`
`
`
`
`MISSING AUDIT .
`DIRECTORY .
`
`NO
`
`68
`
`SUSPCOUS
`
`YES
`
`
`
`
`
`NO
`
`70
`
`NOTFY CONTROL
`FUNCTION
`
`FIG-5B
`
`ZSCALER Ex. 1025 p.7
`
`

`

`U.S. Patent
`
`Jun. 11, 2002
`
`Sheet 7 of 11
`
`US 6,405,318 B1
`
`PORT SCAN DETECTOR
`
`MONITOR INTERNET PORTS
`
`75 FIG 6
`76
`
`
`
`
`
`
`
`77
`
`PORT TO BE
`MONITORED2
`
`PORT BEING
`USED
`LOCALLY?
`
`NO
`PLACE PORT IN
`MONITORED LIST
`
`
`
`REMOVE PORT
`FROM
`MONITORED LIST
`
`
`
`
`
`NUMBER OF
`PORTS
`EXCEEDS MN.
`NUMBERT
`
`
`
`
`
`HOST
`ALREADY
`BLOCKED?
`
`
`
`
`
`NO
`NOTIFY CONTROL FUNCTION
`
`85
`
`78
`
`NO ACTION
`
`ZSCALER Ex. 1025 p.8
`
`

`

`U.S. Patent
`
`Jun. 11, 2002
`
`Sheet 8 of 11
`
`US 6,405,318 B1
`
`
`
`
`
`
`
`
`
`SESSION MONITOR
`
`FOR EACH USER
`
`MONITOR USER COMMAND ENTRIES
`FROM USER'S ACTIVE TERMINAL
`
`MONITOR SYSTEM PROCESS
`ACCOUNTING RECORDS
`
`MONITOR USER'S COMMAND
`HISTORY FILE
`
`
`
`COMPARE COMMAND ENTRIES,
`PROCESS ACCOUNTING RECORDS,
`COMMAND HISTORY FILE TO KNOWN
`ATTACK PATTERNS AND KNOWN
`THREAT EVENTS
`
`90
`
`91
`
`92
`
`93
`
`94
`
`95
`
`C 96
`
`YES
`
`NOTIFY CONTROL FUNCTION
`
`97
`
`FIG-7
`
`ZSCALER Ex. 1025 p.9
`
`

`

`U.S. Patent
`
`Jun. 11, 2002
`
`Sheet 9 of 11
`
`US 6,405,318 B1
`
`CONTROL FUNCTION
`
`NFORMATION ABOUT EVENT RECEIVED
`WTH SIGNATURE INFORMATION
`
`DETERMINE AND TAKE APPROPRIATE ACTION
`
`LOG EVENT TO LOCAL SYSTEM LOC
`
`LOG EVENT TO REMOTE SYSTEM LOG
`
`DSABLE USER ACCOUNT
`
`BLOCK ACCESS TO THE SYSTEM
`
`TRIGGER USER DEFINED ACTION
`
`DROP ROUTE TO THE AT ACKING SYSTEM OR
`USER
`
`BLOCK ACCESS FROM THE OFFENDING SYSTEM
`
`NOTIFY SYSTEM ADMINISTRATOR
`
`125
`
`126
`
`127
`
`128
`
`129
`
`130
`
`131
`
`132
`
`133
`
`134
`
`135
`
`136
`
`GNORE, EVENT
`
`137
`
`
`
`
`
`
`
`
`
`
`
`
`
`S
`CONTROLER
`LOCALP
`
`139
`
`NO
`
`OPTION TO SEND
`YES INFORMATION TO
`LOCAL SYSTEM
`CONTROLLER
`
`SEND TO CENTRAL SYSTEM
`CONTROLLER
`
`138
`
`FIG -8
`
`ZSCALER Ex. 1025 p.10
`
`

`

`U.S. Patent
`
`Jun. 11, 2002
`
`Sheet 10 of 11
`
`US 6,405,318 B1
`
`
`
`99 I
`
`>HTETITIO? || NOO
`TWOOT N | SOH
`
`
`
`XA? JONALEN
`
`2,9]
`
`
`
`
`
`29 I
`
`>|ETTO? || NOO
`TIVO OT| Z | SOH
`
`I G I
`
`>HTETITIO? || NOO
`TIVO OT || || SOH
`
`09 I
`
`6–0 I H
`
`ZSCALER Ex. 1025 p.11
`
`

`

`U.S. Patent
`
`Jun. 11, 2002
`
`Sheet 11 of 11
`
`US 6,405,318 B1
`
`
`
`
`
`PROGRAM SETUP FOR
`INTRUSION DETECTION
`SYSTEM
`
`160
`
`PROR TO INITIALIZATION
`OF THE SYSTEM, SYSTEM
`ADMINISTRATOR SELECTS
`PROGRAM FUNCTIONS
`
`161
`
`162
`
`163
`
`164
`
`165
`
`166
`
`167
`
`LOG AUDITING
`
`LOGIN ANOMALY
`DETECTION
`
`LOGOUT ANOMALY
`DETECTION
`
`SESSION MONTOR
`
`PORT SCAN
`DETECTOR
`ACTIONS TO BE
`TAKEN BY CONTROL
`FUNCTION
`
`CHANGE PRE-PROGRAMMED
`ALARM THRESHOLDS OR
`USE PRE-PROGRAMMED
`THRESHOLDS
`
`168
`
`SELECT OPTION FOR
`DISPLAYING WARNINGS
`AND ALARMS
`
`SELECT LOCAL
`CONTROL FUNCTION OR
`CENTRAL FUNCTION
`
`169
`
`170
`
`FIG - 1. O
`
`ZSCALER Ex. 1025 p.12
`
`

`

`US 6,405,318 B1
`
`1
`INTRUSION DETECTION SYSTEM
`TECHNICAL FIELD OF THE INVENTION
`The present invention relates generally to intrusion detec
`tion for a computer System. More particularly, the invention
`is a computer-implemented intrusion detection System and
`method that monitors a computer System for activity indica
`tive of attempted or actual access by unauthorized perSons or
`computers.
`
`BACKGROUND
`Because of the increasing reliance on Internet, Intranet
`and extranet network computer access, intrusion into com
`puter Systems by unauthorized users is a growing problem.
`An intrusion is unauthorized acceSS or attempted acceSS into
`or unauthorized activity in a computer or information SyS
`tem. Intrusion detection technologies are therefore becom
`ing extremely important to improve the overall Security of
`computer Systems. Intrusion detection is the process of
`identifying that an intrusion has been attempted, is occurring
`or has occurred.
`In most intrusion detection Systems, data may be auto
`matically collected and reduced but the analysis of that data
`usually remains manual. Profiling and pattern recognition
`techniques also have been used to analyze the data collected
`and presented to an intrusion detection System. The off-line
`analysis involves determining normal behavior for a user,
`application or System. The normal behavior is then used to
`develop Sets of rules. Significant deviations from the rules,
`referred to as anomalous behavior, may then be flagged as
`potential intrusions. Some intrusion detection Systems,
`based on anomaly detection techniques, look for Statistically
`anomalous behavior, that is, behavior that appears unusual
`when compared to other user behavior. One drawback of
`anomaly detection Systems is that they are prone to both
`false positive and false negative alerts because the rules are
`general in nature and not Specific for the behavior of each
`user. False positives occur when the intrusion detection
`System identifies an event as an intrusion when none has
`occurred. False positives may divert the attention and time
`of the System administrator and Security Staff and if frequent
`enough, may cause a lack of confidence in the intrusion
`detection System. False negatives are instances where the
`intrusion detection System fails to detect an intrusion while
`it is occurring or after it has occurred. The result may be
`Slow or no response to the intrusion that can result in
`financial loSS and System damage. False negatives often
`occur because the models used to profile the anomalous
`behavior do not adequately predict the intruder behavior and
`its result within the computer System.
`Some intrusion detection Systems use expert Systems,
`which are driven from an encoded rule base to monitor
`policy compliance. The expert System applies the rules to
`assure all users are operating within their privileged rights.
`Even in the expert System, the encoded rules are usually
`generated by profiling the anomalous behavior and then
`building a rule based System. This means that the expert
`System intrusion detection System at present Suffers from the
`Same problems. Such as false positives and false negatives as
`the anomalous detection Systems. Other Systems have pas
`Sive monitor functions that continually analyze data pre
`Sented to them. They are Similar to antivirus functions in that
`they can only detect what has been defined to them. Another
`type of intrusion detection System is a Scanner. Unlike other
`intrusion detection tools that report when a threshold has
`been exceeded, Scanners actively attempt to find Security
`holes (called vulnerabilities) and unauthorized hardware and
`Software.
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`The above mentioned intrusion detection methods have
`many drawbacks. One is that the Systems can only detect and
`monitor what has been previously defined to them, either
`using expert System rules or rules developed through data
`collection reduction and analysis or through profiling. This
`can result in false negatives because unknown attacks have
`not been previously defined. In addition, most Systems only
`analyze and develop profiles and patterns after the fact.
`These profiles and patterns of behavior are Subsequently
`incorporated into rule-based Systems to recognize future
`attacks. Even in those instances where alerts are issued in
`near real-time, valuable time and the intruder's trail can be
`lost. In addition, many of these Systems require human
`intervention, both in the initial analysis of data and profile
`and pattern recognition building Steps and when an anoma
`lous event has occurred, to determine the action to be taken.
`Relying on human intervention can delay the identification
`of the intrusion and may not prevent network damage or
`exploitation.
`To be able to detect intrusions as they are occurring or
`Soon after, there is a need for the intrusion detection System
`to be a real-time System. There is a need to automatically
`build profiling data Specific for each user or class of users
`that can be used to determine normal actions for a user to
`reduce the occurrence of false alarms and to improve detec
`tion. There is a need for a System that can detect Suspicious
`actions, determine the Source and institute autonomous
`responses. There is also a need for the intrusion detection
`System to take automatic action, without waiting for a
`human administrator to intervene and act, to mitigate the
`effects of an intrusion and to prevent future actions. There is
`also a need to coordinate information transfer within host,
`multi-host and network environments so responses to intru
`Sions can be coordinated. In addition, there is a need to
`combine the above listed capabilities with real-time moni
`toring of log audit files, port Scan detection capability and
`Session monitoring.
`
`SUMMARY
`The present invention provides a real-time intrusion
`detection method and System. The intrusion detection Sys
`tem automatically and dynamically builds user profile data
`(known as a signature) for each user (or alternatively, a class
`of users) that can be used to determine normal actions for
`each user to reduce the occurrence of false alarms and to
`improve detection. The user profile data (signature) is saved
`and updated every time the user logs on and off the System.
`The advantage of dynamically building user profile data
`based on past user behavior and comparing it to that user's
`current behavior is that the number of false alarms is
`reduced. In addition, there is no need to enter Sets of rules
`prior to System initialization. The System detects Suspicious
`actions, determines the Source and institutes autonomous
`responses. The System acts to mitigate the effects of an
`intrusion and to prevent future actions without waiting for
`human action. The automatic actions to be taken can be
`Specified by the System administrator prior to initialization
`of the System. The automatic actions can be tailored to
`address the Specific anomaly detected by the intrusion
`detection System. For example, through a local or System
`controller, the System can log the events, disable user
`accounts and block access to the System. In one
`embodiment, the System coordinates information transfer
`within host, multi-host and network environments to coor
`dinate intrusion response. The System combines the above
`listed capabilities with real-time monitoring of log audit
`files, port Scan detection capability and Session monitoring.
`
`ZSCALER Ex. 1025 p.13
`
`

`

`US 6,405,318 B1
`
`3
`Throughout this document, use of the terms dynamic or
`dynamically in relation to a proceSS means that the proceSS
`is operating in real-time or close to real-time.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`These and other features, aspects and advantages of the
`present invention will become better understood with regard
`to the following description, appended claims and accom
`panying drawings where:
`FIG. 1 shows a functional block diagram of the host based
`intrusion detection System.
`FIG. 2 is a block diagram of the log file auditing function.
`FIG. 3 is a flow diagram of the login anomaly detection
`function.
`FIG. 4 is a flow diagram of the user profile database and
`active user database update function
`FIGS.5A and 5B are flow diagrams of the logout anomaly
`detection function.
`FIG. 6 is a flow diagram of the portscan detector function.
`FIG. 7 is a flow diagram of the session monitor function.
`FIG. 8 is a flow diagram of the controller function.
`FIG. 9 is a block diagram of an alternate embodiment of
`a host based intrusion detection System having a central
`System controller.
`FIG. 10 is a flow diagram of program setup for the
`intrusion detection Systems.
`
`15
`
`25
`
`DETAILED DESCRIPTION OF THE DRAWINGS
`FIG. 1 shows a functional block diagram of the intrusion
`detection system. The system is comprised of a log audit
`function 2, a login anomaly detection function 3, a logout
`anomaly detection 7, a Session monitor function 4 and a port
`Scan detector function 5 interfacing with a local controller
`function 6. The log audit function 2, login anomaly detection
`function 3, logout anomaly detection function 7, Session
`monitoring function 4 and port Scan detector function 5 all
`operate in real-time to detect activity indicative of an attack
`by unauthorized users or Systems. The log audit function
`continuously monitorS System log files for anomalous activ
`ity which can include known Suspicious activity and
`unknown System anomalies. When anomalous behavior
`occurs, the log audit function 2 notifies the controller 6 and
`sends information about the activity to the controller 6 for
`further processing. The log auditing function 2 is described
`in FIG. 2. The login anomaly detection function 3 monitors
`System login activity and when anomalous behavior is
`detected, notifies the controller and sends information about
`the activity to the controller 6 for further processing. The
`login anomaly detection function 3 is described in FIG. 3.
`The logout anomaly detection function 7 monitorS System
`logout activity and if anomalous behavior is detected, noti
`fies the controller and sends information about the activity to
`the controller 6 for further processing. The logout anomaly
`detection function 7 is described in FIG. 5. The session
`monitoring function 4 watches user activity after a login has
`been established. The function continuously watches key
`Strokes for known attack Signatures and Suspicious activity.
`Signatures are kept in a user-editable database on the local
`machine. Once Suspicious or known attack activity is
`detected, the Session monitor 4 will Send information about
`the activity to the controller 6 for further processing. The
`session monitoring function 4 is described in FIG. 7. The
`port Scan detector function 5 monitors Internet ports (Such as
`TCP and UDP) for port scanning activity which is a method
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`used by attackers to determine the Vulnerabilities of a target
`host and to run a Series of attacks to gain entry on the
`vulnerable target host. When the port scan detection function
`5 detects port Scanning activity, it sends information about
`the activity to the controller for further processing. The port
`Scan detector function 5 is described in FIG. 6. The con
`troller function 6 controls all actions that the host-based
`intrusion detection System may perform upon being notified
`from the log audit function 2, the login anomaly detection
`function 3, the logout anomaly detection function 7, the
`Session monitor 4 or the port Scan detector function 5 that an
`anomalous activity has occurred, the controller takes an
`appropriate action based on that activity. The controller
`function is described in FIG. 8.
`Turning now to FIG. 2, a block diagram of the log file
`auditing function is shown. The log auditing function 10
`monitors the System login auditing files 11 by comparing the
`log file activity known attack events 12, known Security
`violations 13, and events to ignore 14. If the log file activity
`indicates a known attack event 12 or a known Security
`Violation 13 indicating a Suspicious event or unknown event
`has occurred or is in the process of occurring, then the log
`auditing function 10 constructs a message containing the log
`file information and Signature identification information and
`forwards it to the controller for action. The log auditing
`function can run on a periodic basis with the period Selected
`by the user or it can run continuously in real-time. The user
`has the flexibility to add or remove functions within the
`login anomaly detection to customize the System.
`Turning now to FIG. 3, a flow diagram of the login
`anomaly detection function 20 is shown. The system moni
`tors login and logout audit files and logs (records) all logins
`and logouts for the target host 21. The target host is the
`computer that the user is logging into or logging out of. The
`System login auditing files may be login records (Such as
`wtmp and utmp records) for a Unix(E) based operating
`system or may be event logs for a Windows NT(F) operating
`system. The system checks to determine if the user should be
`ignored 38. Certain users are not checked for login or logout
`anomalies. If the user is to be ignored processing continues
`at Step 35 where the user is logged into the System. If the user
`is not to be ignored and if the user is logging in to the System,
`the monitor builds/updates the user profile database 22 and
`updates the active user database as shown in FIG. 4. The
`system administrator has the flexibility to add or remove
`functions within the logout anomaly detection to customize
`the System.
`Turning now to FIG. 4, a flow diagram is shown of the
`user profile database and active user database update func
`tion. If the user is not in the user profile database 23, then the
`user is a new user and process first login function is executed
`24. A new user profile entry is created 24 which contains the
`user name, the login host, the login terminal (sometimes
`called the TTY), the time of creating the initial user profile,
`the time of the user's first login, the Set days and hours the
`user is allowed login access, the version of the database
`record type and Sets the initial number of logins to one. In
`addition, the System administrator notified whenever a user
`logs into a host for the first time. If the user is already in the
`user profile database 23, then a user profile entry already
`exists for this user and that profile is updated 25. The updates
`to the user profile include appending the login time, login
`host and incrementing the total number of logins. The
`System also checks to determine that the user's login account
`is still valid, that is that it has not been disabled by a system
`administrator. An entry is created in the active user database
`36 which contains the user's name, the terminal the user is
`
`ZSCALER Ex. 1025 p.14
`
`

`

`US 6,405,318 B1
`
`S
`logged in on, the time of login for this entry and the version
`of the database record.
`Turning back to FIG. 3, the next step is to check to
`determine if the login is from a foreign domain 26. A foreign
`domain is one that is not contained within or allowed acceSS
`to the host where the login is attempted. The list of allowed
`domains within the System is accessed 27 and if the login
`domain is not listed, it is considered foreign and the control
`function is notified 37.
`The user login is checked to determine if there are
`multiple concurrent logins for the same user 28 A multiple
`concurrent login means that a user is logged into the System
`more than once from one or more different hosts concur
`rently. This type of behavior may indicate an intrusion. The
`log file is checked to determine if a user is logged in from
`one or more different hosts concurrently. If So and the user
`is not allowed to have multiple logins 29, then this login
`entry is denied and the multiple users are logged off from the
`system 30.
`The next Step is to determine if the user is logged in at an
`unusual time 31. For each user, a profile is automatically
`built of the days, times and length of time that the user has
`logged in. Once a certain threshold number of user logins
`have occurred for this user to allow for accurate user
`profiling (usually approximately ten logins, but this can be
`adjusted by the user), the day and time of the current user's
`attempted login is compared to that profile. If the current
`login time differs from the user's login profile, the control
`function is notified 37.
`The next step is to compare the login activity with known
`attack patterns 34. If the login activity is Similar to a known
`attack pattern, then the control function is notified 37. Next
`the history file is checked for Suspicious command entries
`39.
`If these Steps are Successfully completed, the user is
`logged in 35 and the user's profile database entry is updated
`and the active user database is updated to track the login
`State of the user.
`Turning now to FIGS. 5A and 5B, flow diagrams of the
`logout anomaly detection function are shown. When a user
`attempts to logout, the logout anomaly detector 49 goes
`through a Series of Steps to process the logout to determine
`if Something has occurred during the user's login time that
`may indicate a System anomaly. The logout entry for the user
`is updated in the user profile and the active user database is
`updated 50. If the user is to be ignored 65, then no other
`checking is done and the user is Successfully logged out 70.
`The next step is to determine if the user's file history has
`been compromised 51. If the history file no longer exists 52,
`the history file has been truncated 53 or the history file is a
`Symbolic link 54, the event is logged and information about
`the event is sent to the controller 55. The system examines
`the rhost file and other System authentication files to deter
`mine if dangerous Security modifications to the host file have
`occurred 56. For example, entering a wildcard Symbol,
`allows the host to allow anyone to log in without a password.
`If the host has been altered to allow anyone to login without
`a password or if other activity has occurred that may
`compromise Security, the event is logged and information
`about the event is sent to the controller. The next step is to
`determine if the user's home directory contains one or more
`suspicious directories 59. Intruders will sometimes name a
`local directory in an odd way to hide their work. The system
`checks for known suspicious directories 60 and if it finds
`any, it may log the event and Send information about the
`event to the controller 55. If a network computer process
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`(Sometimes called a “daemon”) is left operating after logout
`63 this could indicate a Suspicious login and event is logged
`and information about the event is sent to the controller 55.
`The System checks to determine if the System audit records
`have been altered or are missing 66. If So, the control
`function is notified 55. Next the program checks an admin
`istrator generated list of generic files to see if one or more
`of them exists in the user's home directory 67. If so, the
`control function is notified. Next, if a Suspicious directory
`name is found 68, the control function is notified 55. If an
`rhost file exists, the control function is notified 69.
`Turning now to FIG. 6, a flow diagram of the port scan
`detector is shown. Port Scanning is a method used by
`attackers to determine the Vulnerabilities of a target host.
`Once Vulnerabilities are found, a Series of attacks are usually
`run to gain entry. Port scanning makes use of the TCP/IP
`protocol, which is the core communication protocol of the
`Internet. It allows machines to communicate throughout the
`world in a reliable manner. One of its features is the use of
`protocol "ports' on remote and originating Systems to estab
`lish connections between hosts. The ports available on a host
`are usually between the ranges of 1 to 65535, with ports 1
`to 1024 being what is commonly referred to as “reserved”
`for use by critical Internet Services. Each port that presents
`a Service to a remote user is usually registered with the
`Internet Assigned Numbers Authority registry (IANA). This
`registration ensures that programs know what ports to avoid
`or specifically connect to depending on the Services being
`requested. Examples of commonly used ports are:
`21-File Transfer Protocol (FTP) services.
`25–Simple Mail Transfer Protocol (SMTP) services.
`80–HTTP services (WWW servers)
`When an attacker is looking for a new host to penetrate,
`they will often begin by looking for Internet programs that
`have known exploitable problems. These programs (called
`“daemons') vary in number and degree of Susceptibility to
`problems. AS new problems are found the hacker commu
`nity quickly makes use of them to penetrate more hosts. To
`facilitate looking for new victims, the attacker will use a
`program that may either: connect to all ports on the remote
`machine or deliberately pick one or more ports to Search for
`a particular problem. Some of the ports may not answer, in
`which case the attacker moves on. Other ports will answer
`and the attacker can then glimpse at what problems they can
`take advantage of. Often attackers will go from host to host
`on the Internet looking for the Same problem to exploit. An
`example port Scan of a host may return the following
`information:
`
`localhost
`localhost
`localhost
`localhost
`localhost
`localhost
`
`telnet
`smtp
`finger
`http
`pop
`imap
`
`23/tcp
`25/tcp
`79/tcp
`80/tcp
`110/tcp
`143/tcp
`
`The port Scan detector of the present invention alerts admin
`istrators that a perSon is actively looking for Services on their
`host in a manner that indicates a hostile action. In the above
`port Scan example our detector could present “fake” ports
`that an attacker will likely Scan for. This could change the
`above port Scan into the following:
`
`ZSCALER Ex. 1025 p.15
`
`

`

`US 6,405,318 B1
`
`7
`
`localhost
`localhost
`localhost
`localhost
`localhost
`localhost
`
`fake
`smtp
`fake
`http
`fake
`fake
`
`23/tcp
`25/tcp
`79/tcp
`80/tcp
`110/tcp
`143/tcp
`
`(Fake port)
`
`(Fake port)
`
`(Fake port)
`(Fake port)
`
`So even though in our example System there are only ports
`25 and 80 active, the other ports will be tripwired by the port
`Scan detector waiting for an attacker to unwittingly try to
`connect to them. When this occurs, the administrator or
`program can then take action to prevent this activity. In FIG.
`6, a flowchart of the portscan detector function 75 is shown.
`Internet ports (such as TCP and UCP) are monitored 76. If
`the port is in a list indicating that the port is not to be
`monitored 77, processing ends and no action is taken 78. If
`the port is in a list indicating it is to be monitored 77, the next
`step is to determine if the port is being used locally 79. If the
`port is being used locally it is temporarily removed from the
`monitored list until it is no longer used locally 80. If the port
`is not being used locally, the port is placed in the list of ports
`to be monitored 81. If the terminal or host computer where
`the user is attempting to log in from is a terminal or host to
`be ignored for port scanning 82, no action is taken 78. If the
`terminal or host computer is not to be ignored 82, then if the
`number of ports that are being Scanned is less than a
`minimum number of ports 83, no action is taken 78. If the
`number of ports that are potentially being Scanned is greater
`than or equal to the minimum number of ports 83, the next
`Step is to determine if the terminal or host computer where
`the user is attempting to log in from is already blocked from
`the system 84. If so, no action is taken 78. If not, information
`about the apparent port Scan is sent to the controller 85 and
`the controller then takes the appropriate action as discussed
`in FIGS. 8 and 9 below. The appropriate actions can vary
`from logging the event, blocking access to the computer
`System from the attacking host or executing a user-Supplied
`command.
`Turning now to FIG. 7, a flow diagram of the session
`monitoring function 90 is shown. For each user, the session
`monitor continuously monitors user activity for a threat to
`the computer system 91. It continuously monitors the user
`command entries 92, the System process accounting records
`93, and commands entered by the user as stored in the user's
`command history file 94. It compares the command entries
`92, System process accounting records 93 and commands in
`the user's command history file to known threat events and
`known attack patterns indicating a computer intrusion 95. If
`a match occurs 96, information and notification is sent to the
`control function 97. In either case the continuous session
`monitoring process continues its dynamic monitoring at Step
`91.
`Turning now to FIG. 8, a flow diagram of the control
`functio