<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Agent on Inliniac</title>
    <link>https://inliniac.net/blog/tag/agent/</link>
    <description>Recent content in Agent on Inliniac</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Fri, 24 Aug 2007 16:26:47 +0000</lastBuildDate>
    <atom:link href="https://inliniac.net/blog/tag/agent/feed.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Follow up on Sguil securtiy</title>
      <link>https://inliniac.net/blog/2007/08/24/follow-up-on-sguil-securtiy/</link>
      <pubDate>Fri, 24 Aug 2007 16:26:47 +0000</pubDate>
      <guid>https://inliniac.net/blog/2007/08/24/follow-up-on-sguil-securtiy/</guid>
      <description>&lt;p&gt;In the discussion about my post about Sguil security there have been a number of ideas and general thoughts. I&amp;rsquo;d like to write about them here to we can further discuss them. There seems to be consensus on that when a sensors is rooted, there is nothing we can do to prevent injection of bogus data as long as it isn&amp;rsquo;t malformed.&lt;/p&gt;&#xA;&lt;p&gt;Having the agent authenticate itself is a solution, but it relies on the agent credentials to remain secret. So when a webserver is rooted the attacker will have access to the credentials as they will be stored on the webserver itself. So this approach does provide an extra layer of defense but local roots aren&amp;rsquo;t uncommon, so it remains risky. It may still be worth the effort though.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Thoughts on Sguil security</title>
      <link>https://inliniac.net/blog/2007/08/24/thoughts-on-sguil-security/</link>
      <pubDate>Thu, 23 Aug 2007 22:25:26 +0000</pubDate>
      <guid>https://inliniac.net/blog/2007/08/24/thoughts-on-sguil-security/</guid>
      <description>&lt;p&gt;Sguil is build using a server and sensors. Traditionally the sensors are passive monitoring agents running Snort and a few other tools. Best practice was (and still is) to separate the management network of these sensors and server from the monitored network(s). This way it would be fairly hard for an attacker to get a shot at the Sguil server.&lt;/p&gt;&#xA;&lt;p&gt;Sguil of course, would be a extremely interesting target for hackers. It contains so much info about the monitored network. Also, it has realtime access to all network traffic. A hacker may also be interested in shutting Sguil down to avoid detection.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Modsec2sguil 0.7 released</title>
      <link>https://inliniac.net/blog/2007/03/18/modsec2sguil-07-released/</link>
      <pubDate>Sun, 18 Mar 2007 10:41:28 +0000</pubDate>
      <guid>https://inliniac.net/blog/2007/03/18/modsec2sguil-07-released/</guid>
      <description>&lt;p&gt;I&amp;rsquo;ve just released version 0.7 of Modsec2sguil, the set of perl scripts to feed ModSecurity alerts to the Sguil NSM system. The main change of this release is that it adds support for alerts produced by ModSecurity 2.x, while 1.9.x remains to be supported. Next to this the conversion between ModSecurity&amp;rsquo;s severity and Snort&amp;rsquo;s priority was fixed, so alerts should show up in the right pane in Sguil again.&lt;/p&gt;&#xA;&lt;p&gt;Please give this release a try and let me know how it works for you!&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
