-------------------------------------------

DEMARC Network Security Monitor

       ::User Guide::

Website: http://demarc.org/
Updated: November 12, 2001


NOTE: Unless this is November, 2001, this 
document is most likely outdated.  
Please visit http://demarc.org/ for
the latest updates to the User Guide. 

DEMARC 2000-2001, DEMARC Organization

-------------------------------------------



1. User Administration
    1 Adding a New User 
    2 Allowing/Disallowing Anonymous Access 
    3 User Levels 
    4 Modifying an Existing User 
    5 Deleting a User 
    6 Restricting Where a User Can Log In From 

2. NIDS Module
    1 Configuring Snort Rules From the Web Interface 
    2 Validate Rules Option 
    3 Automatic Updating of Rulesets and Ruleset/Signature Exclusions 
    4 NIDS Priorities in DEMARC 

3. Host/Service Module
    1 Adding Remote Host/Service Event 
    2 Monitoring DNS Changes 
    3 Adding Local Host/Service Event 
    4 Modifying Remote Host/Service Event 
    5 Modifying Local Host/Service Event 
    6 Deleting Host/Service Event 
    7 Monitoring Local Server Logs 
    8 Monitoring Local Processes 

4. Integrity Module
    1 Integrity Overview 
    2 Configuring File/Web Integrity Checks 
    3 Sample Rules 

5. Configuring Alerts For All Modules
    1 Adding NIDS Alerts 
    2 Modifying NIDS Alerts 
    3 Deleting NIDS Alerts 
    4 Adding Host/Service Alerts 
    5 Modifying Host/Service Alerts 
    6 Deleting Host/Service Alerts 
    7 Adding Integrity Alerts 
    8 Modifying Intergrity Alerts 
    9 Deleting Intergrity Alerts 
 


-------------------------------------------------------------
1-1 Adding a New User
-------------------------------------------------------------

To add a new user, you must be logged in as a Super User.

Click : "configure" on the top menu bar, then
"Configure Users" from the menu that appears.

You must enter:

+ A Username

+ A Password of 4 or more characters.  
   The password may not be the same as the username.

Optional:

+ Email Address
    This will be the email address that non-admin users must
    use to receive alerts (unless the option for non-admin
    users to be able to change their email address is set
    in the DEMARC_config.pm file).  This simply serves as 
    the default email address for administrative accounts.

+ IP Restrictions
    You can use this field to restrict users so that they 
    may only log in from certain IP addresses / ranges.

    The format for this is to have each address or range of
    addresses separated by a ";". IP address ranges are NOT
    in CIDR format, instead, a range is simply denoted by
    specifying a starting and ending number for each part of
    the IP address.
    For example, these are all valid entries:
        192.168.0.1
        192.168.0.1;192.168.0.2
        192.168.0.1-255
        192.168.0.1-255;192.168.0-20.1-255

+ Super User (checkbox)
    By checking this box, the user will have full
    administrative powers in the DEMARC console.
    Note: This is the only class of user that is allowed to
    add/edit/delete users on the system.

+ NIDS Admin (checkbox)
    By checking this box, the user will have the ability to
    administrate the Network Intrusion Detection System (NIDS)
    part of the DEMARC Console.  This includes being able to
    modify Snort rulesets.

+ Host/Service Admin (checkbox)
    By checking this box, the user will have the ability to
    administrate the Host/Service part of the DEMARC Console.
    This includes the ability to add/modify/delete hosts or
    services that are being monitored.

+ Integrity Admin (checkbox)
    By checking this box, the user will have the ability to
    administrate the File/WWW Integrity part of the DEMARC
    Console.  This includes the ability to add/modify/delete
    files or web pages that are being monitored.

When you have finished selecting the options for the new user,
simply press the "Add User" button to finish adding the new user.

-------------------------------------------------------------
1-2 Allowing/Disallowing Anonymous Access 
-------------------------------------------------------------
You can allow/disallow anonymous access to the DEMARC Console by
editing the "/usr/local/demarc/cgi/DEMARC_config.pm" file and
changing the following variable:

# To allow anonymous access:
$conf{'allow_anonymous_access'}          = 1;

# To NOT allow anonymous access:
$conf{'allow_anonymous_access'}          = 0;

Note:  If you are using mod_perl, you will have to restart the Apache
server in order for ANY changes made to the DEMARC_config.pm file to
take effect.



-------------------------------------------------------------
1-3 User Levels
-------------------------------------------------------------
# Super User #

A "Super User" has full administrative powers in the DEMARC console.
Note: This is the only class of user that is allowed to add/edit/delete
users on the system.
Note: If a user is a "Super User", they automatically have full
administrative powers and do not need to have the other three levels
of administrative access enabled.

# NIDS Admin #

A "NIDS Admin" has the ability to administrate the Network Intrusion
Detection System (NIDS) part of the DEMARC Console. This includes
being able to modify Snort rulesets.

# Host/Service Admin #

A "Host/Service Admin" has the ability to administrate the
Host/Service part of the DEMARC Console. This includes the ability to
add/modify/delete hosts or services that are being monitored.

# Integrity Admin #

An "Integrity Admin" has the ability to administrate the
File/WWW Integrity part of the DEMARC Console. This includes the
ability to add/modify/delete files or web pages that are being monitored.


# Regular User #

If none of the administrative boxes are checked, the user may only
view the DEMARC Console and may not change any configuration in it.
The only exception being that a regular user can enter new
"Alert Rules" so that s/he may receive alerts for requested events.
Note: By default, users are allowed to specify an email address to use
when scheduling alert events.  If you would like to lock them into
the one address specified in their account, edit the
"/usr/local/demarc/cgi/DEMARC_config.pm" file and change the
applicable variable to "0" as shown:

$conf{'allow_user_to_change_email'}      = 0;

# Anonymous Users #

If anonymous access is enabled in the DEMARC_config.pm file, anonymous
users are allowed to view the DEMARC Console, but are NOT allowed to
make any configuration changes, and are also NOT allowed to schedule
any "Alert Rules".



 


-------------------------------------------------------------
1-4 Modifying an Existing User 
-------------------------------------------------------------
To modify an existing user, you must be logged in as a Super User.

Click : "configure" on the top menu bar, then "Configure Users"
from the menu that appears.

Select the user you would like to modify from the dropdown menu under
the form entitled "Modify/Delete User".

Select the action you would like to perform from the dropdown menu
next to the selected user:

Change Password To:
     Changes the user's password to the new password you specify in
     the "Input" field to the right.
     
Change Email Address To:
     Changes the user's email address to the new email address you
     specify in the "Input" field to the right.
     
Change IP Restrictions To:
     Changes the restrictions placed on which IP addresses the user
     may login from.  For more detailed instructions on the format for
     this field, see the section entitled "Restricting Where a User
     Can Log In From".
     Note: If this field is left blank, the user may login from any
     IP address.
     
Make user a Super User:
     Escalates the user to "Super User" status.  This is the highest
     level in the system and should be assigned carefully.
     
Revoke user's Super User status:
     Take away Super User status from the selected user.
     
Make user NIDS Admin:
     Escalates the user to "NIDS Admin" status.  This will allow the
     user to configure and administrate the Network Intrusion
     Detection System (NIDS) portion of the DEMARC Console. This
     includes being able to modify snort rulesets.
     
Revoke user's NIDS Admin status:
     Take away NIDS Admin status from the selected user.
     
Make user Host/Service Admin:
     Escalates the user to "Host/Service Admin" status.  This will
     allow the user to configure and administrate the Host/Service
     portion of the DEMARC Console. This includes the ability to
     add/modify/delete hosts or services that are being monitored.
     
Revoke user's Host/Service Admin status:
     Take away Host/Service Admin status from the selected user.
     
Make user File / WWW Integrity Admin:
     Escalates the user to "File / WWW Integrity Admin" status.
     This will allow the user to configure and administrate the
     File / WWW Integrity portion of the DEMARC Console. This includes
     the ability to add/modify/delete files or web pages that are
     being monitored.

Revoke user's File / WWW  NIDS Admin status:
     Take away File / WWW Integrity Admin status from the selected user.
     
Delete:
     Delete the selected user.




Once you have selected the correct options, click the "Update" button
to commit your changes.


-------------------------------------------------------------
1-5 Deleting a User
-------------------------------------------------------------
To delete an existing user, you must be logged in as a Super User.

Click : "configure" on the top menu bar, then "Configure Users"
from the menu that appears.

Select the user you would like to delete from the dropdown menu under
the form entitled "Modify/Delete User".

Select "Delete" from the dropdown menu next to the selected user.


Click the "Update" button to delete the selected user.



-------------------------------------------------------------
1-6 Restricting Where a User Can Log In From 
-------------------------------------------------------------
You can restrict users so that they may only log in from certain IP
addresses / ranges by modifying the "IP Restrictions" field of a
current user, or adding a new user with "IP Restrictions".

The format for this field is to have each address or range of addresses
separated by a ";". IP address ranges are NOT in CIDR format, instead,
a range is simply denoted by specifying a starting and ending number
for each part of the IP address.

For example, these are all valid entries: 
192.168.0.1 
192.168.0.1;192.168.0.2 
192.168.0.1-255 
192.168.0.1-255;192.168.0-20.1-255


The following are NOT valid formats:
192.168.0.0/24 (NOTE: *NOT* valid!)
192.168.0.0 255.255.255.0 (NOTE: *NOT* valid!)


-------------------------------------------------------------
2-1 Configuring Snort Rules From the Web Interface 
-------------------------------------------------------------
To configure Snort rules, you must be logged in as
either a Super User or a NIDS Admin.

Click : "configure" on the top menu bar, then "Configure NIDS Rules"
from the menu that appears.

The "Sensor Details" table will appear.  In this table you will be
able to see all the different sensors configured for use in the DEMARC
Console.  You will see one entry for each interface on which Snort is
configured to run.  Therefore, you might see the same machine listed
more than once, but each entry should have a unique interface listed.
This table will also give you details on when the last time the rules
for this sensor were updated, as well as the last time the sensor
retrieved the last changed version of the rules.  If the rules have
been changed, but have not been updated by the sensor for more than
10 minutes an alert will appear in that entry with the option of
marking that sensor "In-Sync" manually.  Please note that this will
_not_ cause the sensor to update the rules, this will simply get rid
of the message - which is useful if you have a sensor that is offline
and you do not wish to see the warning message anymore.

Click on the hostname for the sensor you wish to configure.

There are two types of configuration "files" you can edit in this
section.
   There is "snort.conf" which should contain the configuration
for Snort such as the database credentials as well as the definitions
for such variables as "HOME_NET" and "EXTERNAL_NET".
   The second type is the rulesets.  The way you classify the
different rulesets is up to you, but we suggest you follow the
guidelines set forth at http://www.snort.org
   Note: There is only one snort.conf for each sensor, but there can
be unlimited Snort rulesets.

For further information on how to configure snort rulesets and for
current rulesets please visit http://www.snort.org/

To edit snort.conf:
    Choose "snort.conf" from the dropdown menu and click "Go".  If
    there is an existing snort.conf for this sensor it will appear in
    a textbox where you may then edit its content.  If one does not
    exist yet, you may enter/past a new snort.conf file into the textbox.
    Once you are finished editing the snort.conf file, make sure "Update"
    is selected below the textbox and click the "Go" button next to the
    dropdown menu.

To add a new ruleset:
    Choose "Create a NEW ruleset" from the dropdown menu and click
    "Go".  Enter a name for the new ruleset (all ruleset names must be
    unique for each sensor) in the textfield that appears.  Then
    enter/paste in the new rules for this ruleset in the textbox.
    When you have finished entering the new rules, make sure "Update"
    is selected in the dropdown menu below the textbox and press the
    "Go" button to the right of the menu.

To edit an existing ruleset:
    Select the ruleset you wish to edit from the dropdown menu and
    click "Go".  Edit the rules as needed on the screen that appears.
     When you have finished editing the ruleset, make sure "Update"
    is selected in the dropdown menu below the textbox and press the
    "Go" button to the right of the menu.

There are other options in the dropdown menu below the textbox that
appears when editing any ruleset or snort.conf entry.  This is where
you will find special options such as "Delete" to delete the ruleset
you are editing, or "Copy ruleset to..." / "Copy ALL rulesets..."
which will allow you to move rulesets between sensors or bring new
sensors online more easily.




-------------------------------------------------------------
2-2 Validate Rules Option 
-------------------------------------------------------------

To validate Snort rules, you must be logged in as
either a Super User or a NIDS Admin.

Click : "configure" on the top menu bar, then "Configure NIDS Rules" 
from the menu that appears. 

The "Sensor Details" table will appear.

Click on the hostname for the sensor's rules you wish to validate.

Click the "Validate" button on the page that appears.

A page will appear that displays the results of the validation test:

GREEN:
   The snort.conf and all rulesets validated correctly.

YELLOW:
   No keywords were found to tell DEMARC whether the rulesets
   validated correctly or not.  This should rarely happen, if ever,
   but if it does, a likely cause is that the Snort binary was not
   found to test the rulesets with.  Please examine the output
   supplied to determine if this is the case.

RED:
   There was an error detected in the config.
   If this is the case, the offending line will appear at the bottom
   of the textarea to help you find which ruleset it is in.
     

Some Important Notes about Validating Rules:

Since DEMARC is run as the unprivileged user that runs the webserver,
Snort can not be started normally because that user does not have the
necessary permissions.  This is overcome by special flags that
reassign the logging directory to one that the webserver has
permission to write to, as well as feeding it a blank tcpdump file to
read instead of having it enter promiscuous mode.  The only
restraint that has yet to be overcome is if you are using "FlexResponse"
rules which requires root privileges to test.  This will not apply to
the majority of Snort users, but if you are - please note that all rules
that contain the "resp:" keyword are commented out before validation is
attempted to avoid failing for this reason.


 


-------------------------------------------------------------
2-3 Automatic Updating of Rulesets and Ruleset/Signature Exclusions
-------------------------------------------------------------
Automatic updating of rules is handled on a per-sensor basis.

In order for autoupdates to work, each sensor that will use this
feature must have a connection to the Internet and have the "lynx"
program installed (http://lynx.browser.org/).  In the future, other
options such as wget will be supported, but for now lynx is used
because it has the ability to easily handle downloads/tar.gz files
with STDOUT as in the following example:

lynx  -source http://snort.sourcefire.com/downloads/snortrules.tar.gz
| tar Ozxvf - rules/*rules  rules/*config 2>/dev/null


This option should not be enabled unless you fully understand the
possible security ramifications. It is possible (although improbable) that
someone could compromise your DNS server and reroute one of the trusted
rules servers to their server that would happily deliver bad rules, or ones
that could be used to escape detection, or worse.  This is only a disclaimer,
like the warning on the NutraSweet packets, but it IS a possibility, and therefore
requires consideration before you enable this option.

Having said that, your current options are to get the new rules from
www.snort.org (aka www.sourcefire.com) or www.whitehats.com


If you choose the snort.org option it WILL override any rulesets you currently have
that bear the same name as a file they are trying to update. There are many files
included and it would be wise to check the current ruleset to see which files will
be overwritten before altering any rulesets via the web.  To be safe, all custom
rules should be given a personal name like "2-yourdomain-web_rules" to make sure it
will never be overwritten by this feature.

If you choose whitehats.com, it will only create/clobber one ruleset : "2-whitehat_rules"
the "2-" is prepended so that it takes a relatively high priority when being
written to the live snort.conf file. (Rules are written to the live
server in alphanumeric order)

This feature is enabled in the demarcd.conf file found in
/usr/local/demarc/conf as follows:

# To update rules from snort.org/sourcefire:
auto_update_snort_rules = sourcefire

# OR to update rules from whitehats:
auto_update_snort_rules = whitehats

# OR to update from both:
auto_update_snort_rules =  sourcefirewhitehats



# This brings up the issue of excluding certain rules/rulesets so that
they are not updated with the rest of the rules.

An example of the need to exclude an entire ruleset would be that by default
the "ICMP RULES" ruleset would be updated/created from www.snort.org.
However, this ruleset usually causes a lot of events to be generated and many
admins choose to not include this ruleset in their production machines.

This could be done by placing the following line in the snort.conf for
a particular sensor:

   EXCLUDE_AUTOUPDATE_RULESET "ICMP RULES"

An example of the need to exclude a specific signature would be if you
have patched against the IIS Code Red/Nimbda worms, but the signatures keep
triggering events that you do not need to see, however you do not want to exclude
the entire WEB-IIS ruleset.

This could be done by placing the following line in the snort.conf for
a particular sensor:

   EXCLUDE_AUTOUPDATE_SIGNATURE "WEB-IIS cmd.exe access"

Note: for excluding signature, only include the "msg:" in the
definition as shown above.


-------------------------------------------------------------
2-4 NIDS Priorities in DEMARC 
-------------------------------------------------------------
Priorities for NIDS events are configured by adding a
"P--" to the beginning of a particular signature.

There are 6 priority levels for DEMARC alerts, priority level 1 being
the highest and 6 being the lowest.  All events that don't contain a
priority assignment default to priority level 2.

Priority level 1 ("P-1-") is equivalent to a "Red Alert" in the DEMARC
Console, and Priority level 2 ("P-2-") is a "Yellow Alert".

For example, the following signature would now be considered Priority
1, or a "Red Alert" in the DEMARC Console:

   alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 \
   (msg:"P-1-WEB-IIS cmd? acess";flags: A+; content:".cmd?&"; nocase; classtype:\
   attempted-user; sid:1003; rev:1;)



So what's the use of priorities?

If you do not wish to see a particular signature come up on the Quick Stats
section or the Miniview window, you can make it a priority of 3 or
below and it will not be displayed in the "Last NIDS Alert" section.

If you want a particular signature to trigger a bigger alarm, you can
mark it as priority 1, then by setting your NIDS Alerts rules to
alert you only in case of RED alerts, you'll cut down on the
false-alarm email alerts, and can be confident that it will be
something you are really interested in seeing if you receive an
email/page.



You also have the option when you are editing a particular ruleset
to change the priorities of all the signatures.



Note: This priority scheme was developed in the days before Snort 1.8
when Snort did not have its own classification priority settings for
the rules.  There are plans to phase the current DEMARC priority
feature out in favor for Snort's built-in classification scheme.


-------------------------------------------------------------
3-1 Adding Remote Host/Service Event 
-------------------------------------------------------------

To add a remote monitoring event, you must be logged in as
either a Super User or a Host/Service Admin.

Click "configure" on the top menu bar, then "Add Host/Service
to Monitor" from the menu that appears.

You may choose to use an existing host to monitor by selecting the
hostname from the dropdown menu on the left or define a new host by
entering a new hostname in the textfield to the right.  If you are
creating a new host, you must also either specify an existing group
for the new host by selecting one from the "Existing Group" dropdown
menu, or define a new group by typing one in in the "New Group"
textfield.

Since you want to monitor a remote service, you'll need to use the
part of the form entitled "Add New Remote Service to Monitor".  Select
the service you'd like to monitor from the "Service" dropdown menu.
If you are monitoring the service on a standard port you may simply
click the "Create Monitoring Event" button at this point.  If the
service you wish to monitor is on a non-standard port, such as a web
server running on port 8080, you can specify the port number by typing
it in the "Port" textfield before submitting the form.

If you'd like to monitor a remote service that is not listed, you may
use one of the the "TCP" services and simply specify the port the remote
service is listening on.  This is a generic TCP connect test that will
simply report whether or not it was able to successfully complete a TCP
handshake on the specified port.

Note: See the following section entitled "Monitoring DNS Changes" for 
details on the DNS option of this form.


 


-------------------------------------------------------------
3-2 Monitoring DNS Changes 
-------------------------------------------------------------
When you are adding a new monitoring event, there is the option to
"Check for DNS changes?".  The purpose of this feature is to trigger a
Red Alert if the IP address changes for this hostname.  This is a
great way to check for DNS hijacking or a misbehaving DNS server.

There are a couple notes you should keep in mind when using this
feature:

- You only need to have the DNS check set for one service on each of
  the hosts you wish to monitor.  If you set the DNS check on more
  than one of the services for a particular host, each service will
  raise a separate Red Alert when the DNS changes for that host.

- The Red Alert that is raised when the DNS changes only stays red for
  one cycle of demarcd (which by default is 5 minutes), so you should
  have demarcd set to email you for Red Alerts on this host, or keep a
  trained eye on the console to avoid missing this potentially
  critical alert.




-------------------------------------------------------------
3-3 Adding Local Host/Service Event 
-------------------------------------------------------------
To add a local monitoring event, you must be logged in as
either a Super User or a Host/Service Admin.

Click "configure" on the top menu bar, then "Add Host/Service
to Monitor" from the menu that appears.

You may choose to use an existing host to monitor by selecting the
hostname from the dropdown menu on the left or define a new host by
entering a new hostname in the textfield to the right.  If you are
creating a new host, you must also either specify an existing group
for the new host by selecting one from the "Existing Group" dropdown
menu, or define a new group by typing one in in the "New Group"
textfield.

Since you want to monitor a local service, you'll need to use the
part of the form entitled "Add New Local Service to Monitor".  Select
the service you'd like to monitor from the "Service" dropdown menu.
Since this will be a local host check, you'll need to tell DEMARC
which SID (DEMARC Sensor) will be performing this local check.  For
example, if I want to check the diskspace on a sensor named
"serverace" I would select that sensor from the "SID" dropdown menu.
In order for the sensor to check this local service, you'll need to
have the demarcd client running on the remote sensor.

When you have made your selections, click "Create Monitoring Event" to
submit the form.




-------------------------------------------------------------
3-4 Modifying Remote Host/Service Event
-------------------------------------------------------------
To modify a remote monitoring event, you must be logged in as
either a Super User or a Host/Service Admin.

Click "monitor" on the top menu bar, then click on the remote
service you want to modify on a particular host.

On the detail screen that appears click the link that says
"Edit Monitoring of  on this Host".

From this screen you can change:

  -the hostname

  -the grouping (but only to another predefined group)

  -the port that the service is running on
   (this will be blank if it is the default por for that service)

  -whether or not DNS should be checked for changes (ie DNS hijacking)
  
   
Choose "Update" from the dropdown menu next to the "Confirm" button at
the bottom of the form and then click "Confirm" to update this
specific monitoring event.



-------------------------------------------------------------
3-5 Modifying Local Host/Service Event
-------------------------------------------------------------
To modify a local monitoring event, you must be logged in as
either a Super User or a Host/Service Admin.

Click "monitor" on the top menu bar, then click on the local
service you want to modify on a particular host.

On the detail screen that appears, click the link that says
"Edit Monitoring of  on this Host".

From this screen you can change:

  -the hostname

  -the grouping (but only to another predefined group)

  -the SID (DEMARC Sensor) that should perform this check locally.

  -whether or not DNS should be checked for changes (ie DNS hijacking)
  
   
Choose "Update" from the dropdown menu next to the "Confirm" button at
the bottom of the form and then click "Confirm" to update this
specific monitoring event.


-------------------------------------------------------------
3-6 Deleting Host/Service Event 
-------------------------------------------------------------
To delete a monitored event, you must be logged in as
either a Super User or a Host/Service Admin.

Click "monitor" on the top menu bar, then click on the service you
want to delete on a particular host.

On the detail screen that appears, click the link that says
"Edit Monitoring of  on this Host".

Choose "Delete" from the dropdown menu next to the "Confirm" button at
the bottom of the form and then click "Confirm" to delete this
specific monitoring event.


-------------------------------------------------------------
3-7 Monitoring Local Server Logs 
-------------------------------------------------------------
You can use DEMARC to monitor your logfiles so that you will be
alerted to certain events such as invalid logins or an interface going
into promiscuous mode.

To do this you must be logged in as either a Super User or a Host/Service Admin.

# To initially add this type of monitoring for a sensor:

Click "configure" on the top menu bar, then "Add Host/Service
to Monitor" from the menu that appears.

Use the form on the bottom of the page entitled "Special Service
Monitoring Section".  Select the hostname that you want to be
attributed with this sensor from the dropdown menu on the left.
Please note that you may not define a new hostname when adding this
monitoring event, you must instead use a hostname that is already
being monitored.  Then select the Sensor on which this check will be
performed.  The "demarcd" client process must be running on the
selected Sensor.  Select "Logs" from the "Service" dropdown menu on
the right and then click the button below to create the new monitoring
event.

This will bring you to a page that allows you to edit the rules for
the log monitoring on this Sensor.  The rules for how to define valid
rules are on this page, as well as in the section below entitled
"Rules Format".


# To edit the rules for this monitoring event:

Click "monitor" on the top menu bar, then click on the icon under the
"Logs" Heading on the host you wish to modify.

On the detail screen that appears click the link that says 
"Edit Monitoring of Logs on this Host".

From this screen you can change:

-the hostname 

-the grouping (but only to another predefined group) 

-the SID (DEMARC Sensor) that should perform this check locally. 

-whether or not DNS should be checked for changes (ie DNS hijacking) 


If you'd like to change the rules for the log monitor, click the "Edit
Log Monitoring Rules" link.

# Rules Format

Rules should be in the form:

alert_level;path_to_logfile;target_regex;threshhold_number;comment_or_description
 
  
alert_level Options: red or yellow

        The level of alert that will be generated if the number of matching
        log entries fall outside of specified parameters.
 
path_to_logfile

         The path to the logfile that should be monitored.
         (ie /var/log/messages)

target_regex

         The string or simple regex that will match the log enties you wish
         to monitor.
         ie: INVALID LOGIN or
         kernel.*promiscuous (would match kernel: fxp0: promiscuous mode enabled)
 
threshhold_number

        If the number number of matches in the logfile reaches or passes this
        number, the specified alert_level will be generated.
        Default is 1.
        
comment_or_description

        Optional comment or description that will appear if this alert is triggered.
        (ie: "Too many invalid logins")




When you have finished editing the log monitoring rules, click
"Update" to commit the changes.


Note:  Once Rules have been updated, [INODE=###][PREV_MATCHES=###] appears in the rule.
       Leave this there unless you are an advanced user. These values stop DEMARC from
       notifying you more than once about the same violation



-------------------------------------------------------------
3-8 Monitoring Local Processes
-------------------------------------------------------------
You can use DEMARC to monitor your local processes so that you will be
alerted if a process terminated unexpectedly.

DEMARC also allows you to specify a "Regeneration Command" and user
which will cause demarc to attempt to regenerate the terminated
command automatically without the need for user intervention.

To do this you must be logged in as either a Super User or a Host/Service Admin.

# To initially add this type of monitoring for a sensor:

Click "configure" on the top menu bar, then "Add Host/Service
to Monitor" from the menu that appears.

Use the form on the bottom of the page entitled "Special Service
Monitoring Section".  Select the hostname that you want to be
attributed with this sensor from the dropdown menu on the left.
Please note that you may not define a new hostname when adding this
monitoring event, you must instead use a hostname that is already
being monitored.  Then select the Sensor on which this check will be
performed.  The "demarcd" client process must be running on the
selected Sensor.  Select "Procs" from the "Service" dropdown menu on
the right and then click the button below to create the new monitoring
event.

This will bring you to a page that allows you to edit the rules for
the process monitoring on this Sensor.  The rules for how to define valid
rules are on this page, as well as in the section below entitled
"Rules Format".


# To edit the rules for this monitoring event:

Click "monitor" on the top menu bar, then click on the icon under the
"Procs" Heading on the host you wish to modify.

On the detail screen that appears click the link that says 
"Edit Monitoring of Proc on this Host".

From this screen you can change:

-the hostname 

-the grouping (but only to another predefined group) 

-the SID (DEMARC Sensor) that should perform this check locally. 

-whether or not DNS should be checked for changes (ie DNS hijacking) 


If you'd like to change the rules for the log monitor, click the "Edit
Process Monitoring Rules" link.

# Rules Format

Rules should be in the form:

alert_level;process_regex;min;max;comment_or_description;regen_cmd;regen_user
 
  
alert_level

     Options: red or yellow
     The level of alert that will be generated if this process falls
     outside of specified parameters.
 
process_regex

     The string or simple regex that will match the process you wish to monitor.
     ie: a regex such as"httpd.*conf" which would match
     "httpd -DSSL -f /usr/local/www/conf/httpd.conf"
     or you can use a simple string such as "named" which would match
     "named" and/or "named -u bind -b /etc/nameddb/named.conf"
 
min

     The minimum number of processes that should match process_regex.
     If the actual number falls below the minimum number, the specified
     alert_level will be generated. Default is 1.

max

     The maximum number of processes that should match process_regex. If the
     actual number goes above the maximum number, the specified alert_level
     will be generated. Default is 0 (unlimited).
     
comment_or_description

     Optional comment or description that will appear if this file/directory
     is modified. (ie: "System Configuration Files")
     
regen_cmd (optional)

     "regen_cmd" (Regeneration Command) is the command that should be run if
     the number of matching processes fall below the min number specified. In
     order for this command to be executed, a matching command MUST be in the
     "regen.cmds" file in the "/usr/local/demarc/conf" directory on the host
     in which this command will be executed. This is for your safety, as
     commands have the potential to be run as root.

   NOTE: this command will be executed as defined, and the perl script will wait 10
      seconds for control to return to the program, if control is not restored,
      the script will attempt kill the process.
      Moral: if this command does not automatically background itself, add a "&"
      to the end of it.
 
regen_user (optional)

     "regen_user" (Regeneration User) is the user that the command specified in
     "regen_cmd" should be run as.



When you have finished editing the log monitoring rules, click
"Update" to commit the changes.


Further note on renen.cmds file:
  This file is for your safety.  It's not too hard to imagine a
  situation where a rouge admin enters a regeneration command such as
  "rm -rf /" or "echo 'bad_entry' >> /etc/passwd" which would easily
  wreak havoc with the security of your DEMARC sensors.  By using this
  regen.cmds file, the command that is to be executed to regenerate a
  process must be defined in this "/usr/local/demarc/conf/regen.cmds"
  file - which requires root access to edit.  Therefore it can be
  assumed that if an admin already has root access on the target
  sensor, there's no further risk in allowing them to specify a
  regeneration command to be executed on the machine.

  As an example, if you wanted to make sure named was running on a
  sensor, and you defined "/usr/sbin/named -u bind -b
  /etc/nameddb/named.conf" as the regeneration command through the web
  interface, the EXACT same command would have to be entered in the
  regen.cmds file as follows:
  root;/usr/sbin/named -u bind -b /etc/nameddb/named.conf
  if it were to be allowed to be run as root.
  For an example of a command that would be run as a different user,
  and would actually require multiple commands to execute, we can take
  the following example where we want to make sure our AudioGalaxy
  client is always running, and if it dies, we should regenerate it
  as the "nobody" user:
  nobody;cd /usr/home/you/bin/ && /usr/home/you/ag/AGSatellite&



-------------------------------------------------------------
4-1 Integrity Overview 
-------------------------------------------------------------
The File/Web Integrity module checks specified files for signs of tampering.
It can also check web pages for changes which can be used to make sure
your site has not been defaced, or simply to let you know when your
favorite website changes the content on a particular page.

Many times when people compromise a machine, they'll replace some of
the system binaries to allow them to return or snoop around the
computer without being detected.  Although they can change many
characteristics of the modified file to attempt to make the changes
unnoticeable, theres no way to trick a MD5 hash.  A MD5 hash is a sort
of a cryptographic fingerprint for files, so even if only one bit has
changed in the file, the MD5 hash will no longer match that of the
unmodified file.  This is the basic concept behind file integrity checks.
By default, DEMARC checks all specified files once every half an hour
for signs of changes.  Although the MD5 hash should suffice for signs
of tampering, DEMARC checks many other characteristics for signs of
change as well:

File Integrity Checks monitor:

 * Inode Number
 * File Permissions
 * User ID of owner
 * Group ID of owner
 * Size of the file
 * Modified timestamp
 * Created timestamp
 * MD5 hash of the file


Web Integrity Checks monitor:

 * Size of the webpage downloaded
 * MD5 hash of the downloaded webpage




If you are monitoring a large number of files, it can increase the
load on the system noticeably, therefore this check is not performed
every 5 minutes like the host/service checks are.  Instead (by
default) the File/Web Integrity checks are performed once every half
hour, but this value is configurable in the demarcd.conf file.

When the file integrity checks are being performed, DEMARC lets you
know this by changing the process name of the client.  You can see
this by typing "demarcd [-i ] -g" which would produce
results similar to the following:

# demarcd -g
###############################################################
Attempting to list all running snort and/or demarcd processes
###############################################################
<truncated>  11:57.99 DEMARC Client CHECKING MD5s (fxp0) (X)
<truncated>  3:59.74 /usr/local/bin/snort -o -q -i fxp0 -c /usr/...


The "CHECKING MD5s" will disappear when the check has completed.


-------------------------------------------------------------
4-2 Configuring File/Web Integrity Checks 
-------------------------------------------------------------
To configure File/Web Integrity checks, you must be logged in as
either a Super User or a File/Web Integrity Admin.

Click "configure" on the top menu bar, then "Configure Integrity
Checks" from the menu that appears.

Choose the sensor on which the file/web integrity checks should be
performed from the drop down list and click "Change" to configure the
rules for that sensor.

Enter the rules for the sensor in the textbox that appears, one per
line, in the following format:

   alert_level;path;recursive_if_directory;comment_or_description
 
  
alert_level

       Options: red , yellow , or IGNORE
       The level of alert that will be generated if this file/directory/website
       is modified. "IGNORE" allows you to specify files that shall be excluded
       from previously defined directory checks.
       NOTE: only files may be ignored at this time.
       
path

       The path to the file or directory you wish to monitor.
       This can now also be a URL to a http protocol webpage (no https support).
       ie: "/etc/hosts" or "http://www.your_site.com/index.html"

recursive_if_directory

       Options: 1 or 0
       If this path is a directory, "1" here will cause the directory
       to be recursed so that all subdirectories will be checked. "0"
       means that only the files within this directory should be checked.
       NOTE: This option is ignored if the entry is for a website.

comment_or_description

       Optional comment or description that will appear if this
       file/directory/website is modified.
       (ie: "System Configuration Files" or "Company Home Page")





When you have finished entering rules, click "Update" to commit the
changes.




-------------------------------------------------------------
4-3 Sample Rules 
-------------------------------------------------------------
Below is an example set of rules that you can use to get started
writing File/Web Integrity rules.  These rules should be modified and
expanded to match the needs of your particular system, but should
serve as a good base for building upon.




IGNORE;/root/.bash_history;0;Changes every time root logs out
RED;/bin/csh;0;Shell
RED;/bin/df;0;SU/GID Files files
RED;/bin/rcp;0;SU/GID Files files
RED;/bin/sh;0;Shell
RED;/bin/tcsh;0;Shell
RED;/boot;0;Boot Files
RED;/etc/master.passwd;0;System Master Passwd File (w/shadow passwords)
RED;/etc/passwd;0;System Password file
RED;/kernel;0;System Kernel
RED;/sbin/ccdconfig;0;SU/GID Files files
RED;/sbin/dmesg;0;SU/GID Files files
RED;/sbin/dump;0;SU/GID Files files
RED;/sbin/ping;0;SU/GID Files files
RED;/sbin/ping6;0;SU/GID Files files
RED;/sbin/rdump;0;SU/GID Files files
RED;/sbin/restore;0;SU/GID Files files
RED;/sbin/route;0;SU/GID Files files
RED;/sbin/rrestore;0;SU/GID Files files
RED;/sbin/shutdown;0;SU/GID Files files
RED;/usr/bin/at;0;SU/GID Files files
RED;/usr/bin/atq;0;SU/GID Files files
RED;/usr/bin/atrm;0;SU/GID Files files
RED;/usr/bin/batch;0;SU/GID Files files
RED;/usr/bin/chfn;0;SU/GID Files files
RED;/usr/bin/chpass;0;SU/GID Files files
RED;/usr/bin/chsh;0;SU/GID Files files
RED;/usr/bin/crontab;0;SU/GID Files files
RED;/usr/bin/cu;0;SU/GID Files files
RED;/usr/bin/fstat;0;SU/GID Files files
RED;/usr/bin/ipcs;0;SU/GID Files files
RED;/usr/bin/keyinfo;0;SU/GID Files files
RED;/usr/bin/keyinit;0;SU/GID Files files
RED;/usr/bin/lock;0;SU/GID Files files
RED;/usr/bin/login;0;SU/GID Files files
RED;/usr/bin/lpq;0;SU/GID Files files
RED;/usr/bin/lpr;0;SU/GID Files files
RED;/usr/bin/lprm;0;SU/GID Files files
RED;/usr/bin/man;0;SU/GID Files files
RED;/usr/bin/netstat;0;SU/GID Files files
RED;/usr/bin/nfsstat;0;SU/GID Files files
RED;/usr/bin/passwd;0;SU/GID Files files
RED;/usr/bin/quota;0;SU/GID Files files
RED;/usr/bin/rlogin;0;SU/GID Files files
RED;/usr/bin/rsh;0;SU/GID Files files
RED;/usr/bin/su;0;SU/GID Files files
RED;/usr/bin/systat;0;SU/GID Files files
RED;/usr/bin/top;0;SU/GID Files files
RED;/usr/bin/uucp;0;SU/GID Files files
RED;/usr/local/bin/bash;0;Shell
RED;/bin/bash;0;Shell
YELLOW;/bin;1;System Executables and Libraries
YELLOW;/etc;0;System Config Files
YELLOW;/root;0;Root's Home Directory
YELLOW;/sbin;1;System Executables and Libraries
YELLOW;/usr/bin;0;System Executables and Libraries
YELLOW;/usr/lib;0;System Executables and Libraries
YELLOW;/usr/local/bin;1;User Executables
YELLOW;/usr/local/etc;1;User Level Config Files
YELLOW;/usr/local/sbin;1;User Executables
YELLOW;/usr/sbin;0;System Executables and Libraries
YELLOW;/var/run;1;Mostly PIDs


-------------------------------------------------------------
5-1 Adding NIDS Alerts
-------------------------------------------------------------
Click : "configure" on the top menu bar, then 
"Configure NIDS Alerts" from the menu that appears.

In the top form entitled "Add New IDS Monitor Alert" you may specify
the criteria for your alert rule.

For the most general alert rule that would email you on every NIDS
alert for any sensor, simply enter your email address and leave the
other options as their defaults.  Click "Add Event" to complete the
addition of the new rule.

You can optionally make a more specific rule that will only alert you
if certain defined conditions are met.

You may choose any number of the following optional criteria, however
a boolean "AND" is performed to create the criteria for the alert.  For
example, if you choose a specific alert priority and a specific
signature, you will only be alerted if there is a NIDS event with the
specified signature AND priority.



Alert Priority:

      By default, all NIDS alerts are "YELLOW/P-2", so if do not have
      highly optimized rules, you'll want to change this field to
      "RED/P-1" or else you'll never stop getting emails from DEMARC
      with every NIDS event that fires.  Please also realize that
      there are *no* "P-1" rules defined by default, so unless you
      define potentially important rules as "P-1", you'll never
      receive any IDS alerts from DEMARC.
      NOTE: The way priorities are defined will most likely change
      with future releases.  Please see the section entitled "NIDS
      Priorities in DEMARC" for further information on this.


Notify From/Thru:
      These fields allow you to specify which times DEMARC is allowed
      to send you emails.  This is especially useful if you have
      different shifts of responsibility for employees, and alerts
      should be routed to different people during those different
      shifts.  If you do not want any time restrictions on alerts,
      simply leave the defaults of 12 AM - 11 PM.

Existing Signature:
      This dropdown menu contains a list of all signatures that it has
      already seen triggered.  If you select one of these signatures,
      you will only be notified if this one signature appears as an
      event (alert still subject to passing other alert rule criteria).

Signature Contains:
      This field can be used to specify a certain string that must be
      present in a signature message in order to send the alert.  An
      example would be "WEB" which would send an alert for any
      triggered event in which "WEB" is present (alert still subject
      to passing other alert rule criteria).



Once you have selected the desired options, click "Add Event" at the
bottom of the form to complete the addition of the new alert rule.
The event will then be listed below the "Add New IDS Monitor Alert"
form where it can then be edited if necessary.




-------------------------------------------------------------
5-2 Modifying NIDS Alerts 
-------------------------------------------------------------
Click : "configure" on the top menu bar, then
"Configure NIDS Alerts" from the menu that appears.

Below the top form entitled "Add New IDS Monitor Alert", you'll find a
list of currently configured alert rules.  If you are a Super User or
NIDS Admin you'll be able to see all alerts in the system.  If you are
not an administrator you'll only be able to see the alerts configured
for yourself.

You may only edit one rule at a time, and must click the "Confirm"
button with "Update" selected after editing each rule in order to
commit the changes.

NOTE: For details on what the different options mean, please see the
section entitled "Adding NIDS Alerts".




-------------------------------------------------------------
5-3 Deleting NIDS Alerts
-------------------------------------------------------------
Click : "configure" on the top menu bar, then
"Configure NIDS Alerts" from the menu that appears.

Below the top form entitled "Add New IDS Monitor Alert", you'll find a
list of currently configured alert rules.  If you are a Super User or
NIDS Admin you'll be able to see all alerts in the system.  If you are
not an administrator you'll only be able to see the alerts configured
for yourself.

You may only delete one rule at a time, and must click the "Confirm"
button with "Delete" selected from the dropdown menu next to it after
editing each rule in order to commit the deletion.


-------------------------------------------------------------
5-4 Adding Host/Service Alerts 
-------------------------------------------------------------
Click : "configure" on the top menu bar, then
"Configure Host/Service Alerts" from the menu that appears.

In the top form entitled "Add New Host/Service Monitor Alert" you may
specify the criteria for your alert rule.

For the most general alert rule that would email you on every change 
in status for any host, simply enter your email address and leave the 
other options as their defaults. Click "Add Event" to complete the 
addition of the new rule. 

You can optionally make a more specific rule that will only alert you 
if certain defined conditions are met. 

You may choose any number of the following optional criteria, however 
a boolean "AND" is performed to create the criteria for the alert. For 
example, if you choose a specific alert level and a specific
service, you will only be alerted if there is an event with the
specified service AND alert level.


Hostname:

    You may select a particular monitored host for which you would
    like to receive alerts by selecting one from this drop down list.

Group:

    You may select a particular predefined group for which you would
    like to receive alerts by selecting one from this drop down list.

Notify of REDs until Resolved:

    This option allows you to specify if you'd like to receive continual
    alerts if a host/service stays in a Red (critical) state.  If you
    select "No" for this option, you will only be notified once when
    the host/service changes to a Red Alert state, and then again when
    it changes to another state.

Notify of YELLOWs until Resolved:

    This option allows you to specify if you'd like to receive continual
    alerts if a host/service stays in a Yellow (warning) state.  If you
    select "No" for this option, you will only be notified once when
    the host/service changes to a Yellow Alert state, and then again when
    it changes to another state.

Maximum Alert Frequency:

    Assuming that you have one of the previous two options selected,
    you may limit the rate at which the repetitive alerts are sent by
    selecting one of the options from this dropdown menu. For example,
    if you have selected that you would like to be alerted to Red
    Alerts until they have been resolved, but select "30 Minutes" as
    the "Maximum Alert Frequency" then you'll be notified of a Red
    Alert every thirty minutes until it has been resolved.

Notify From/Thru:

    These fields allow you to specify which times DEMARC is allowed
    to send you emails. This is especially useful if you have
    different shifts of responsibility for employees, and alerts
    should be routed to different people during those different
    shifts. If you do not want any time restrictions on alerts,
    simply leave the defaults of 12 AM - 11 PM.

Alert Level:

    This field specifies what level(s) of alerts you would like to be
    notified of.  If you leave the default of "ANY", then any change
    in status for a host/service will cause an email to be generated
    (assuming the other criteria set forth has been satisfied).  If
    you specify a certain alert level, the rule will only match when a
    host/service changes to the specified alert level.  In most cases
    you'll want to keep this as ANY, although a manager type might
    only want to get alerts if there is a Red Alert.




Once you have selected the desired options, click "Add Event" at the 
bottom of the form to complete the addition of the new alert rule. 
The event will then be listed below the "Add New Host/Service Monitor
Alert" form where it can then be edited if necessary.


-------------------------------------------------------------
5-5 Modifying Host/Service Alerts 
-------------------------------------------------------------
Click : "configure" on the top menu bar, then
"Configure Host/Service Alerts" from the menu that appears.

Below the top form entitled "Add New Host/Service Monitor Alert", you'll
find a list of currently configured alert rules. If you are a Super User
or Host/Service Admin you'll be able to see all alerts in the system. If
you are not an administrator you'll only be able to see the alerts
configured for yourself.

You may only edit one rule at a time, and must click the "Confirm" 
button with "Update" selected after editing each rule in order to 
commit the changes. 

NOTE: For details on what the different options mean, please see the 
section entitled "Adding Host/Service Alerts".


-------------------------------------------------------------
5-6 Deleting Host/Service Alerts 
-------------------------------------------------------------
Click : "configure" on the top menu bar, then
"Configure Host/Service Alerts" from the menu that appears.

Below the top form entitled "Add New Host/Service Monitor Alert", you'll
find a list of currently configured alert rules. If you are a Super User
or Host/Service Admin you'll be able to see all alerts in the system. If
you are not an administrator you'll only be able to see the alerts
configured for yourself.

You may only delete one rule at a time, and must click the "Confirm"
button with "Delete" selected from the dropdown menu next to it after 
editing each rule in order to commit the deletion.


-------------------------------------------------------------
5-7 Adding Integrity Alerts 
-------------------------------------------------------------
Click : "configure" on the top menu bar, then
"Configure Integrity Check Alerts" from the menu that appears.

In the top form entitled "Add New File/Web Integrity Alert" you may
specify the criteria for your alert rule.

For the most general alert rule that would email you on every change 
in any priority rule for any sensor, simply enter your email address
and leave the other options as their defaults. Click "Add Event" to
complete the addition of the new rule.

You can optionally make a more specific rule that will only alert you 
if certain defined conditions are met. 

You may choose any number of the following optional criteria, however 
a boolean "AND" is performed to create the criteria for the alert. For 
example, if you choose a specific alert level and a specific
sensor, you will only be alerted if there is an event on the
specified sensor AND with the specified alert level.


Sensor:

    You may select a particular sensor for which you would
    like to receive alerts by selecting one from this drop down list.

Alert Level:

    This field specifies what level(s) of alerts you would like to be
    notified of.  If you leave the default of "ANY", then any rule
    (either "Red" or "Yellow" rules) will cause an email to be generated
    (assuming the other criteria set forth has been satisfied).  If
    you specify a certain alert level, the rule will only match when
    an Integrity Rule is triggered of the specified alert level.  In
    most cases you'll want to keep this as ANY, although a manager
    type might only want to get alerts if there is a Red Alert.

Notify From/Thru:

    These fields allow you to specify which times DEMARC is allowed
    to send you emails. This is especially useful if you have
    different shifts of responsibility for employees, and alerts
    should be routed to different people during those different
    shifts. If you do not want any time restrictions on alerts,
    simply leave the defaults of 12 AM - 11 PM.

Email Detail Level

    This feature is not implemented at this point.  In future
    releases it will give you control over the level of detail sent via
    email, which can be useful depending on if the alerts are going to
    an email account or a cell phone/pager.



Once you have selected the desired options, click "Add Event" at the 
bottom of the form to complete the addition of the new alert rule. 
The event will then be listed below the "Add New File/Web Integrity
Alert" form where it can then be edited if necessary.


-------------------------------------------------------------
5-8 Modifying Intergrity Alerts 
-------------------------------------------------------------
Click : "configure" on the top menu bar, then
"Configure Integrity Check Alerts" from the menu that appears.

Below the top form entitled "Add New File/Web Integrity Alert", you'll
find a list of currently configured alert rules. If you are a Super User 
or File/Web Integrity Admin you'll be able to see all alerts in the
system. If you are not an administrator you'll only be able to see the
alerts configured for yourself.

You may only edit one rule at a time, and must click the "Confirm" 
button with "Update" selected after editing each rule in order to 
commit the changes. 

NOTE: For details on what the different options mean, please see the 
section entitled "Adding File/Web Integrity Alerts".



-------------------------------------------------------------
5-9 Deleting Intergrity Alerts 
-------------------------------------------------------------
Click : "configure" on the top menu bar, then
"Configure Integrity Check Alerts" from the menu that appears.

Below the top form entitled "Add New File/Web Integrity Alert", you'll
find a list of currently configured alert rules. If you are a Super User 
or File/Web Integrity Admin you'll be able to see all alerts in the
system. If you are not an administrator you'll only be able to see the
alerts configured for yourself.

You may only delete one rule at a time, and must click the "Confirm"
button with "Delete" selected from the dropdown menu next to it after 
editing each rule in order to commit the deletion



-------------------------------------------------------------







