<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>multicepT. Service auf den Punkt gebracht. &#187; Security</title>
	<atom:link href="http://www.multicept.de/blog/category/security/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.multicept.de/blog</link>
	<description></description>
	<lastBuildDate>Tue, 15 Jun 2010 17:05:59 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<language>de</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Tripwire und KVM ergänzen sich</title>
		<link>http://www.multicept.de/blog/42/tripwire-und-kvm-erganzen-sich/</link>
		<comments>http://www.multicept.de/blog/42/tripwire-und-kvm-erganzen-sich/#comments</comments>
		<pubDate>Thu, 21 Jan 2010 21:49:04 +0000</pubDate>
		<dc:creator>Oliver Herms</dc:creator>
				<category><![CDATA[Linux]]></category>
		<category><![CDATA[Monitoring]]></category>
		<category><![CDATA[Security]]></category>

		<guid isPermaLink="false">http://www.multicept.de/blog/?p=42</guid>
		<description><![CDATA[Heute haben wir bei einer ersten virtuellen Maschine Tripwire so eingerichtet, dass es nicht innerhalb der virtuellen Maschine läuft, sondern auf dem Hostrechner.
Wozu das ganze? Tripwire kann doch auch im Gast laufen und die Integrität aller Dateien prüfen?
Stimmt, aber dann ist es von einem Angreifer innerhalb der virtuelle Maschine leicht manipulierbar!
Da unsere Tripwire Binarys und [...]]]></description>
			<content:encoded><![CDATA[<p>Heute haben wir bei einer ersten virtuellen Maschine Tripwire so eingerichtet, dass es nicht innerhalb der virtuellen Maschine läuft, sondern auf dem Hostrechner.<span id="more-42"></span></p>
<p>Wozu das ganze? Tripwire kann doch auch im Gast laufen und die Integrität aller Dateien prüfen?</p>
<p>Stimmt, aber dann ist es von einem Angreifer innerhalb der virtuelle Maschine leicht manipulierbar!<br />
Da unsere Tripwire Binarys und Configs nicht in der virtuelle Maschine liegen, sind sie für einen Angreifer nicht greifbar. Er weiß nicht mal, dass eine Tripwire Installation existiert (es sei denn, er liest diesen Blogpost)!</p>
<p>Wie funktioniert das ganze?<br />
Ein Script fertigt von dem Gastsystem per LVM einen Snapshot an, welcher dann mit kpartx als einzelne Partitionen gemountet wird. Auf dem gemounteten Read-Only Volume wird dann der Integritätscheck ausgeführt.</p>
<p>So (!) macht ein HIDS sinn.<br />
Wir werden das Script weiter entwickeln und erproben und es später zum Download bereit stellen.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.multicept.de/blog/42/tripwire-und-kvm-erganzen-sich/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Mod_Security blockt Anfragen aufgrund von IP-Adressen</title>
		<link>http://www.multicept.de/blog/22/mod_security-blockt-anfragen-aufgrund-von-ip-adressen/</link>
		<comments>http://www.multicept.de/blog/22/mod_security-blockt-anfragen-aufgrund-von-ip-adressen/#comments</comments>
		<pubDate>Tue, 12 Jan 2010 16:42:35 +0000</pubDate>
		<dc:creator>Oliver Herms</dc:creator>
				<category><![CDATA[Security]]></category>
		<category><![CDATA[Spam]]></category>
		<category><![CDATA[Webserver]]></category>

		<guid isPermaLink="false">http://www.multicept.de/blog/?p=22</guid>
		<description><![CDATA[Heute rief mich ein bekannter an, er könne unsere Webseiten nicht aufrufen und erhalten einen Fehler 403 (Fordbidden, Zugriff verweigert).
Ein Test von meinem Arbeitsplatz aus, konnte den Fehler ersteinmal nicht bestätigen. Nachdem ich erst das DNS geprüft habe (zeigt die Domain auch auf den richtigen Server?), prüfte ich die Logdatei des Webservers. Tatsache: Seine Anfragen [...]]]></description>
			<content:encoded><![CDATA[<p>Heute rief mich ein bekannter an, er könne unsere Webseiten nicht aufrufen und erhalten einen Fehler 403 (Fordbidden, Zugriff verweigert).</p>
<p>Ein Test von meinem Arbeitsplatz aus, konnte den Fehler ersteinmal nicht bestätigen. Nachdem ich erst das DNS geprüft habe (zeigt die Domain auch auf den richtigen Server?), prüfte ich die Logdatei des Webservers. Tatsache: Seine Anfragen wurden blockiert, meine nicht.<span id="more-22"></span></p>
<p>Die Ursache war die, dass unser Regelwerk in der Datei 00_asl_rbl.conf, welche aus dem Regelwerk von <a href="http://www.gotroot.com/mod_security+rules" target="_blank">gotroot.com</a> stammt, eine Regel enthielt, welche die IP-Adresse des Clients in der DNSBL xbl.spamhaus.org nachschlägt und, falls die IP-Adresse gelistet ist, den Zugriff verweigert. Die Liste enthält eigentlich Rechner, welche durch Spam auf Webseiten durch Trojaner / Botnetze beispielsweise aufgefallen sind. Problematisch ist das ganze jedoch deswegen, weil IP-Adressen sich hierzulande normalerweise nach 24 Stunden ändern und dann ein unschuldiger Benutzer eine IP-Adresse bekommen kann, die auf der Blackliste steht. Diesem Benutzer ist der Besuch unserer Seiten dann nicht möglich.</p>
<p>Fazit: Der Einsatz einer  DNSBL in einer WebApplication Firewall kann also schnell dazu führen, dass unschuldige Besucher von der Webseite ausgesperrt werden.<br />
Anders als Mailserver, haben Websurfer normalerweise nämlich keine festen IP-Adressen.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.multicept.de/blog/22/mod_security-blockt-anfragen-aufgrund-von-ip-adressen/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Linux Local-Root-Exploit lässt uns kalt</title>
		<link>http://www.multicept.de/blog/17/linux-local-root-exploit-lasst-uns-kalt/</link>
		<comments>http://www.multicept.de/blog/17/linux-local-root-exploit-lasst-uns-kalt/#comments</comments>
		<pubDate>Fri, 14 Aug 2009 16:22:01 +0000</pubDate>
		<dc:creator>Oliver Herms</dc:creator>
				<category><![CDATA[Linux]]></category>
		<category><![CDATA[Security]]></category>
		<category><![CDATA[Webserver]]></category>

		<guid isPermaLink="false">http://www.multicept.de/blog/17/linux-local-root-exploit-lasst-uns-kalt/</guid>
		<description><![CDATA[Richtig gelesen!
Obwohl wir auf vielen unserer Server natürlich Linux einsetzen, betreffen uns die meisten Exploits für Linux nicht direkt, da wir einen stark gehärteten Linuxkernel einsetzen. Wir setzen bei allen Systemen, wo Kunden direkten Zugriff auf das System (Shell / CGI) haben auf Grsecurity.
Grsecurity ließ uns bereits im Februar 2008 ruhiger schlafen, als es einen [...]]]></description>
			<content:encoded><![CDATA[<p>Richtig gelesen!</p>
<p>Obwohl wir auf vielen unserer Server natürlich Linux einsetzen, betreffen uns die meisten Exploits für Linux nicht direkt, da wir einen stark gehärteten Linuxkernel einsetzen. Wir setzen bei allen Systemen, wo Kunden direkten Zugriff auf das System (Shell / CGI) haben auf Grsecurity.<span id="more-17"></span></p>
<p>Grsecurity ließ uns bereits im Februar 2008 ruhiger schlafen, als es einen lokalen Rootexploit für Linux gab (Vmsplice Bug). Sämtliche auffindbaren Exploits funktionieren auf unseren Systemen nicht. Und so ist es auch nun wieder: Sämtliche Exploits, die wir für die aktuelle Lücke finden konnten, funktionieren auf unseren Systemen nicht.</p>
<p>Seit heute wollen wir die ganze Welt an unseren Paketen, die für KVM-Gastsysteme mit Debian Lenny konzipiert sind, teilhaben lassen, und stellen die Pakete für amd64 unter <a href="http://grsec.multicept.de" target="_blank">http://grsec.multicept.de</a> zur Verfügung. Dass wir für Probleme, die durch unsere Pakete entstehen keinerlei Haftung übernehmen versteht sich von selbst.</p>
<p>Nähere Informationen, was im Kernel enthalten ist, was nicht, sowie signaturen werden in den nächsten Tagen folgen. Es lohnt sich also die Seite regelmäßig aufzurufen.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.multicept.de/blog/17/linux-local-root-exploit-lasst-uns-kalt/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
