download issue 24 here - Help Net Security

More documents

Recommendations

Info

How can you learn about your environment and how to protect it in a cost-effective manner, enable your organization to respond to incidents when they happen, and satisfy auditors? In my opinion, OSSEC is a good answer to that question. I found out about OSSEC while I was searching the web for log management advice. Back in those days, we had to do a lot of things by ourselves. Apparently Daniel Cid had been encountering the same problems I was, because he decided to do something about it. He developed OSSEC, and released it as open source - which it still is today. You may notice that the rules are defined in .xml files. It is incredibly easy to create your own rules or modify existing rules to fit your requirements. As long as you are somewhat familiar with regular expressions - for xml and the application youʼre creating rules for - there is basically no limit to what you can do with OSSEC. The OSSEC architecture In this article, I'm assuming a client/server installation, since all but one daemon are present in both the client/server and the standalone installation. OSSEC is designed to run Interpret any log, on/from any system OSSECʼs current version is 2.3 and the client runs on Windows, Linux, AIX, Solaris and HP/ UX. The server runs on Linux, AIX, Solaris and HP/UX. Additionally, OSSEC can even monitor systems on which you cannot install the software for whichever reason. The built-in rule base is pretty impressive. Alongside log rules for open source solutions like Apache, MySQL, sendmail and squid, there is also an impressive amount of rules for commercial solutions such as several AV engines, firewalls, networking products and MS Exchange. several daemons, all assigned limited and specific tasks. All but one are running on chroot. Letʼs introduce them: Analysisd runs on chroot as the user ossec and does all the analysis. In a standalone installation this process obviously runs on the client, but in the client/server setup it runs only on the server. The direct benefit is that the resource-intensive analysis of events is executed by the server, which is usually dedicated to doing just that. This leaves the resources craved by your application untouched. www.insecuremag.com 58
Remoted (running on the server) receives the logs from Agentd (running on the client). Remoted is running on chroot (user = ossecr) and Agentd too (user = ossec). Remoted is responsible for all communications with the agents. Monitord is responsible for monitoring the agents and takes care of the centralized logfiles. The daily logs are compressed and signed by this process, too. We have one process doing analysis, one sending events and another receiving them. But, we also need a worker to collect the events, and this task is performed by the logcollector. This daemon is running as root, which is required because it obviously needs access to the logfiles it will monitor. The last two daemons are maild and execd. Maild, running on chroot (user = ossecm) sends mails on specific alerts if e-mail notification is enabled (weʼll see later that this is easily configurable). The final process, which coincidentally converts the HIDS into a HIPS, is execd - the process responsible for starting active responses. This sums up all the functionality offered by OSSEC: we collect logs (logcollector), send them to the server (agentd and remoted), decode and analyze them (analysisd) and we act upon the generated alerts (maild and execd) if so required. Analysis: when gibberish becomes language (pam_unix)$ A log event can contain a lot of information, but we donʼt need all of it. We are interested in the parts that we can use to create actionable alerts. OSSEC does the analysis in three phases: pre-decoding, decoding and analysis. In the first phase - pre-decoding - the information provided by the event source is parsed and known fields are extracted. The time, the system name and the application name are of particular interest here, but the log message is left untouched and passes on to the next phase, decoding. Here, the log message is inspected in depth and information is further extracted. Usually we want to gather information like source IP, username, destination IP, etc. With a basic understanding of regular expressions you can create your own decoders. Letʼs take a look at the default PAM decoder. The first two decoder rules are: ^pam_unix|^$pam_unix$ The first one tells OSSEC to treat any log message for which the program name is (pam_unix) as a PAM message, applying subsequent decoder rules to it. The second rule is to catch those PAM messages that, for one reason or the other, get logged with another program name. Those messages that contain either the string pam_unix or (pam_unix) are still regarded as PAM messages. Now, we need to extract information we can work with from those messages. pam ^session \w+ ^for user (\S+) user www.insecuremag.com 59
Page 5 and 6:
25 million new malware strains in o
Page 7 and 8: Google hacked, plans to leave China
Page 9 and 10: Hacker attacks on healthcare organi
Page 11 and 12: Even though most standard stacks us
Page 13: Server support still missing Unfort
Page 16 and 17: What are these new approaches? Let
Page 18 and 19: The need for new security controls
Page 21 and 22: How many times have you, as a secur
Page 23 and 24: 1Password interface Although this i
Page 25 and 26: The option “Never prompt for mast
Page 27 and 28: The master password on the iPhone a
Page 29 and 30: Identifying those applications is n
Page 31: The single tool trap Scanning tools
Page 34 and 35: Cloud Security and Privacy By Tim M
Page 36: Spam and phishing scams will follow
Page 39 and 40: This infection method only works if
Page 41 and 42: Hook-createprocess.dll is a DLL tha
Page 43: Here are some of the Twitter feeds
Page 46 and 47: organizations the tools they need t
Page 48: This is not unlike other business o
Page 52 and 53: acronyms without researching their
Page 54 and 55: process of calculation the answer.
Page 57: In any environment, large or small,
Page 61 and 62: alpha group alpha events 10000 Ch
Page 63: RSA Conference 2010 (www.bit.ly/rsa
Page 66: And most of the time, they fail bec
Page 69 and 70: We are also working with SANS on de
Page 71 and 72: There are three components involved
Page 73 and 74: " • Support for health checks by
Page 76 and 77: Sectool (www.net-security.org/softw
Page 78 and 79: To achieve this, retailers must shi
show all

download issue 24 here - Help Net Security

Create successful ePaper yourself

Delete template?

Save as template?