ru.internet.security

 
 - RU.INTERNET.SECURITY ---------------------------------------------------------
 From : Marхnais                             2:5020/2173.2  18 Nov 2005  17:10:39
 To : All
 Subject : Desktop Firewalls and Intrusion Detection
 -------------------------------------------------------------------------------- 
 

 
 textsection 10 of 12 of file WUESTE.TXT
 textbegin.section
                               6.1.1 Definitions
 
      The information which all desktop firewalls have in common should be inc-
 luded in the generic event log format. In addition, fields that are  not  pre-
 sent in the log files but still needed should be added by the  parser  script,
 for example, a trust field. After analyzing the log files and  comparing  them
 with IDS and network firewalls log files we came up with a generic  event  log
 format, containing the fields shown in the table below and described next.
 
          description           field name                value
 
 IP address of the sensor       SensorIP    IP address [4 octets]
 Type of the sensor             Type        [ZOA3|SDF2|SPF5]
 Time when the event occurred   Time        Unix timestamp
 Source IP address              SrcIP       IP address [4 octets]
 Source host name               SrcName     <string>
 Source port number             SrcPort     <integer>
 Destination IP address         DestIP      IP address [4 octets]
 Destination host name          DestName    <string>
 Destination port number        DestPort    <integer>
 Action that was performed      Action      [blocked|allowed|ignored|info|N/A]
 Direction                      Direction   [incoming|outgoing|N/A]
 Protocol which was used        Protocol    [TCP|UDP|ICMP|IGMP|N/A]
 Flags or type of the packet    Flag        [SYN|FIN|ECHO_REPLY|...]
 Application which was involved Application <string>
 Level of trust in this event   Trust       [0Д9]
 Signature name                 Signature   <string>
 Entire original message        Msg         <string>
 
 o SensorIP: (mandatory)
      The address of the machine that the desktop firewall is running on.  This
 information could also be calculated by looking at  the  source  address,  the
 destination address and the direction, but this method would fail in some  ca-
 ses. For example, when the packet was sent to a broadcast  address.  In  addi-
 tion, this is an information that is frequently needed, and it makes sense  to
 have it as a self-contained field. This field is filled with the parser script.
 
 o Type: (mandatory)
      The type and version of the desktop firewall that was used. This  can  be
 used to filter out events from a specific vendor. For example, if it is  known
 that those signatures do not match a certain attack very well. Or this  infor-
 mation could be used to write a correlation rule which takes advantage of  the
 peculiarities of a specific firewall. The products used in  this  thesis  have
 been labeled "ZOA3" for "Zonealarm 3", "SDF2" for "Symantec  Desktop  Firewall
 2" and "SPF5" for "Sygate Personal Firewall 5". This field is filled with  the
 parser script.
 
 o Time: (mandatory)
      Simply a common Unix timestamp. Make sure that all monitored machines are
 in the same timezone.
 
 o SrcIP: (optional)
      The address where the traffic came from. It might be empty  if  the  host
 name was given instead.
 
 o SrcName: (optional)
      The host name where the traffic came from. It does not always make  sense
 to convert this name into an address, as the corresponding address might  have
 changed before the conversion took place or the  local  DNS  resolution  might
 have been altered.
 
 o SrcPort: (optional)
      The port number where the traffic came from.
 
 o DestIP: (optional)
      The address where the traffic was sent to.
 
 o DestName: (optional)
      The host name where the traffic was sent to. It does not always make sen-
 se to convert this name into an address, as the  corresponding  address  might
 have changed before the conversion took place  or  the  local  DNS  resolution
 might have been altered.
 
 o DestPort: (optional)
      The port number where the traffic was sent to.
 
 o Action: (mandatory)
      May contain one of the five different strings:
 
      "blocked" Д which means that the traffic was blocked  and  discarded
                  by the desktop firewall. This information can be  useful
                  to verify whether the attack was successful or not.
      "allowed" Д which means that the traffic was  not  blocked  and  did
                  pass the desktop firewall. This information can be  use-
                  ful to verify whether the attack was successful or not.
      "ignored" Д which means that the traffic was logged but not blocked.
      "info"    Д which means that  this  event  is  just  an  information
                  event, like "new rule added for telnet.exe".  When  this
                  parameter is set, then the information of the event  can
                  be found in the "msg" field.
      "N/A"     Д which means none of the above matched or that there  was
                  an error while parsing this event line in  the  original
                  log file.
 
 o Direction: (optional)
      The direction: incoming or outgoing. This information could also be  cal-
 culated by looking at the source and destination addresses, but they could  be
 spoofed. Some of the desktop firewalls, for example, "Zonealarm", seem  to  do
 it like this and fail when we send a packet that has the source  and  destina-
 tion addresses set to the address of the firewall. It will then mark this pac-
 ket as an outgoing traffic, because the source address is the  local  one.  In
 addition, this is an information that is frequently needed, and it makes sense
 to have it as a self-contained field.
 
 o Protocol: (optional)
      The protocol of the packet that was monitored, for example, TCP  or  UDP.
 It is optional, as not all events assume it. For example, informational messa-
 ges do not include a protocol specification.
 
 o Flag: (optional)
      Some additional information of the used protocol, if available. This  can
 be "SYN" if, for example, the SYN flag was set in the packet.
 
 o Application: (optional)
      The name of the application that was sending or receiving the packets  on
 the monitored system.
 
 o Trust: (mandatory)
      Was introduced additionally and cannot be found in the  desktop  firewall
 log files themselves. Its value is a number between 0  and  9  expressing  the
 level of trust that we have in this alarm message. A value of 0 means that  we
 do not trust this alarm and think it is incorrect, while 9 means that we trust
 this alarm and think it is true. This parameter should help to eliminate false
 positives by rating events and, maybe, ignoring an alarm which has a low trus-
 tiness during the correlation. By default a trust level of 5  is  assigned  to
 all the parsed messages. In this thesis the only rule used to modify it is al-
 arms rating. As a result of it, outbound connections from the protected machi-
 ne will have an alarm with the default level +1, and inbound ones will have it
 with the default level Д1. The reason for this is that we  have  more  control
 over the local events and can provide more information on them. Remote  events
 can be easily faked to make us believe whatever the attacker wants us  to  be-
 lieve. For example, a port scan can come from a spoofed source IP address such
 that it looks like it is coming from someone else. Modifying local  events  is
 much harder.
 
 o Signature: (optional)
      The name of the signature that was matched for this alarm. Keep  in  mind
 that the user could have rights to change the rules and,  therefore,  also  to
 rename it to something that does not correspond with the real event. But, when
 controlled, this information can be useful in filtering the events later.
 
 o Msg: (mandatory)
      The whole event message as it appeared in the  original  log  file.  This
 field was added specially for the information messages. If an  event  has  set
 the action to information, then we can find here the specific message  string.
 As there are too many different information messages, it would not make  sense
 to add new fields for each of them. Also it can be used as a fall back if some
 information got lost in the parsing script.
      Some of the fields might stay empty after parsing different  event  logs,
 because not all of the information might be present in the original event mes-
 sage. The event numbers are removed, as they might not be consistent  and  are
 not of interest. The correlation center or central console can, and most  pro-
 bably will, add their own numbering to the events.
                                6.1.2 Exporting
 
      The following are the actual export mappings  into  the  defined  generic
 format for the specific desktop firewalls.
                          "Zonealarm" log file mapping
 
      A typical event in a "Zonealarm" log looks like this:
 
 FWIN,2002/11/25,14:35:52 +1:00 GMT,10.10.10.7:53,10.10.50.2:53,TCP (flags:S)
 
      "Zonealarm" log translation table
 
            FWIN,                           -> Direction
            2002/11/25, 14:35:52 +1:00 GMT, -> Time
            10.10.10.7:53,                  -> SrcIPaddr + SrcPort
            10.10.50.2:53,                  -> DestIPaddr + DestPort
            TCP (flags:S)                   -> Protocol + Flag
            complete string                 -> Msg
            depending on rule               Trust
            set by script                   SensorIP
            set by script                   Type
            set by script                   Action
                  "Symantec Desktop Firewall" log file mapping
 
      A typical event in a "Symantec Desktop Firewall" log looks like this:
 
 11/27/2002 15:50:48 Rule "Implicit block rule" blocked (10.10.50.1,446).
 Details: Inbound TCP connection
 Local address,service is (10.10.50.1,446)
 Remote address,service is (10.10.50.4,1684)
 Process name is "N/A"
 
      "Symantec Desktop Firewall" log translation table
 
              12/27/2002 15:50:48        -> Time
              Rule "Implicit block rule" -> Signature
              blocked                    -> Action
              (10.10.50.1,446). Details: <ignored>
              Inbound TCP connection     -> Direction + Protocol
              Local address,service is   <ignored>
              (10.10.50.1,446)           -> DestIPaddr + DestPort
              Remote address,service is  <ignored>
              (10.10.50.4,1684)          -> SrcIPaddr + SrcPort
              Process name is "N/A"      -> Application
              complete string            -> Msg
              depending on rule          Trust
              set by script              SensorIP
              set by script              Type
 
      Unfortunately, the port numbers of known services are automatically  map-
 ped to their names. This means that, for example, port number 80 will be  rep-
 laced with the string "http" in the log file. This fact is quite annoying, be-
 cause it makes it harder to compare the logs. A switch to disable this  option
 could not be found. For further analysis this has to be remapped to the origi-
 nal port number.
      Another installed feature is resolving the IP addresses into the host na-
 mes, which also cannot be turned off in the configuration.
      Initialization informations, like the ones shown below,  will  be  mapped
 into information messages with the Action parameter set to "info":
 
 1/23/2003 9:19:14 Inbound IGMP packets are being blocked
 1/23/2003 9:19:14 Inbound IP fragments are being blocked
 1/23/2003 9:19:14 NDIS filtering is enabled
 1/23/2003 9:19:14 Interactive learning mode is enabled
 1/23/2003 9:19:14 Firewall configuration updated: 149 rules
              "Sygate Personal Firewall" traffic log file mapping
 
      A typical event in a "Sygate Personal Firewall" traffic  log  looks  like
 this:
 
 32104 11/27/2002 15:55:24 Blocked TCP Incoming 10.10.50.4 1897 10.10.50.3 446ъ
    1 11/27/2002 15:55:11 11/27/2002 15:55:11 Block_all_unknown
 
      "Sygate Personal Firewall" traffic log translation table
 
                       103                 <ignored>
                       11/27/2002 15:55:14 -> Time
                       Port Scan Minor     -> Action
                       Incoming            -> Direction
                       TCP                 -> Protocol
                       10.10.50.4          -> SrcIPaddr
                       10.10.50.3          -> DestIPaddr
                       10                  <ignored>
                       11/27/2002 15:55:10 <ignored>
                       11/27/2002 15:55:13 <ignored>
                       complete string     Msg
                       depending on rule   Trust
                       set by script       SensorIP
                       set by script       Type
               "Sygate Personal Firewall" system log file mapping
 
      Events in the system log file are on a higher  level.  They  are  already
 correlated and look like the events of an internal IDS. This makes them diffe-
 rent than the log files that we have already mapped. Still this information is
 of great value for us, as it compresses events into a one alarm.
      A typical event in a "Sygate Personal Firewall"  system  log  looks  like
 this:
 
 103 11/27/2002 15:55:14 Port Scan Minor Incoming TCP 10.10.50.4 10.10.50.3 10ъ
     11/27/2002 15:55:10 11/27/2002 15:55:13
 
      "Sygate Personal Firewall" system log translation table
 
               32104                <ignored>
               11/27/2002 15:55:24  -> Time
               Blocked TCP Incoming Action + Protocol + Direction
               10.10.50.4           -> SrcIPaddr
               1897                 -> SrcPort
               10.10.50.3           -> DestIPaddr
               446                  -> DestPort
               1                    <ignored>
               11/27/2002 15:55:11  <ignored>
               11/27/2002 15:55:11  <ignored>
               Block all unknown    Signature
               complete string      Msg
               depending on rule    Trust
               set by script        SensorIP
               set by script        Type
                               6.2 Collaboration
 
             6.2.1 Multiple instances of the same desktop firewall
 
      Having multiple instances of the same type of a desktop firewall install-
 ed on different machines might be a common case in a company. This is also the
 same setup that was tested in a real world experiment in Section 6.4.
      These setups are simpler to maintain, because we only have a one type and
 can create a specific rule set using all the provided features. The  advantage
 of this setup against a single installed desktop firewall is that we  have  an
 access to the same information on different machines. With this we can see  if
 a detected attack was only targeting a single machine or a whole subnet.  This
 makes it possible for us to detect attacks that have made only a few events on
 the each machine but a lot in total over all the machines.
      The disadvantage is that, if the chosen desktop firewall has a vulnerabi-
 lity, all the machines in the network are affected in the same way. An attack-
 er could render the complete network unusable by exploiting such a  vulnerabi-
 lity.
 textend.section
 
  * Origin: 2:5020/1317.8, /2024.2, /2173.2, /2613.5, /5413.3 (2:5020/2173.2)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор