RootForum Community

Hallo zusammen,

bin gerade dabei einen neuen Server unter CentOS aufzusetzen
Frage meinerseits welche Repositories setzt Ihr für Eure CentOS Installationen ein
da ja nicht alle Programme im Standard Repository enthalten sind (z.B. fail2ban etc.)

Hoffe Ihr könnt mir hier weiterhelfen.

Danke im voraus.

Gruß, PHPman

Welche Pakete benötigst Du denn die nicht im Upstream-Repo enthalten sind?

z.B. fail2ban, postgrey, clamsmtp, logwatch diese kommen so bei der Installation nicht mit rüber.

elrepo als Stichwort.

fail2ban - Macht mehr Ärger als es nutzt.
postgrey - Greylisting hat ausgedient, die Spammer berücksichtigen es.
clamsmtp - ClamAV taugt nix (zu geringe Erkennungsrate, zu viele Bugs) und frisst zu viele Ressourcen.
logwatch - Dafür benötigt man kein extra Repo welches einem das System verpfuscht, einfach manuell installieren.

Wenn Du also keine wirklich wichtigen Pakete aus Fremd-Repos zwingend benötigst, dann verzichte bitte darauf.

Joe User wrote: fail2ban - Macht mehr Ärger als es nutzt.
clamsmtp - ClamAV taugt nix (zu geringe Erkennungsrate, zu viele Bugs) und frisst zu viele Ressourcen.

FAIL2BAN
Darauf schwören viele Leute. Man kann sich erheblich darüber streiten ob das Ding einen reellen nutzen bringt.
Es macht meiner Meinung nach nicht mehr Ärger als Nutzen.
Allerdings nutzt es nicht viel, wenn man nicht weiss was es tut und wie es tut. Gerade bei den Regexpr. welche einen möglichen Einbruch erkennen sollten, muss der Operator schon geanu wissen, was er konfiguriert.

Bei meinen eingesetzten Distribution, waren die default Konfigurationen nahezu unbrauchbar.
-> Centos und OPENSUSE

Auf Basis der korrigierten Checks war die Erkennungsrate sehr gering. Oder anders gesagt, die Angriffe die fail2ban auf meinem Honeypot ermittelt und abgewehrt hat, wären auf dem Produktionsystem völlig unproblematich gewesen.
Die wirklich interessanten Attacken, die auf Applikationsfehler z.B. Apache Bugs oder derartiges abziehen, hätte das Tool so erstmal nicht gefunden.
Bei erfolgreichen Angriffen (nachdem die Schwachstelle bekannt war und gefixt wurde) hätte man nun einen solchen Angriff anhand möglicher Logeinträge, abweisen können. Wäre aber wegen dem erfolgten Fix auch kein Problem gewesen. Aber nur, wenn man dazu wirklich passende Logeinträge findet. In Produktion loggen wir nicht auf Debuglevel also wird es hier auch schon etwas schwieriger.
Die Lücke ist aber damit nicht geschützt sondern lediglich die Angriffmuster und Angriffsdauer zeitlich limitiert.

Deutlich besser funktionierte ein vorgeschaltetes IDS auf Basis von Snort mit regelmässig aktualisierten Regeln. Es gibt hier einige freie Quellen mit aktuellen und gute Regeln. Diese konnten weit Tiefer in den Netzwerkverkehr einblicken und somit Angriffe frühzeitig erkennen.
Dabei kann der vorgelagerte SNORT Proaktiv auf einen Angriff reagieren wärend fail2ban nur reaktiv einen Angriff ansprechen kann und das auch nur so gut, wie die betroffnen Applikationen in der Lage sind diesen Angriff zu melden. Da liegt der Hase im Pfeffer.

Es bietet aber keinen "Echten" Gewinn an Sicherheit, da die vorhanden Lücken mit diesem Tool nicht gestopft werden. Es kann max. bekannte Angriffmuster auf bekannte Schwachstellen ausbremsen. Ein geziehlter proffesioneller Angriff wird hier erforlgreich sein. Wenn auch nur für kurze Dauer. die aber ist u.U. ausreichend.

Aus meiner Erfahrung mit dem Honeypot: Kein Informationsgewinn für mich statt dessen nur eine Informationsflut belangloser Vorkommnisse.
Das oft genannte Argument "Logfiles klein halten wegen Übersichtlichkeit" zählt bei mir nicht wirklich wer grep ,sort und co anwenden kann, braucht das nicht.

clamsmtp - ClamAV taugt nix (zu geringe Erkennungsrate, zu viele Bugs) und frisst zu viele Ressourcen.

Geringe Erkennungsrate kann ich bestätigen liegt aber mehr am clamd als am clamsmtpd selbst.
Bugs und hoher Ressourcenverbrauch kann ich nicht bestätigen.

Um bei der obigen Aussage zu fail2ban ein Beispiel nach zu liefern wie folgt:

Fail2ban wurde bei mir so konfiguriert, dass er nach 3 erfolglosen Loginversuchen die IP sperren soll.
Je nach Angriffmuster hat das aber leider nicht wirklich gefruchtet.

Typ 1. Paraleller versuch eines Angriffes.
Bis fail2ban erfolgreich den Zugriff verhinderte vegingen mehrere Sekunden, womit der Angeifer bedeutend mehr Loginversuche durchführen konnte als gewollt.
Typ2. Brute Force Attacken aus einem "Botnetz" wurden kurzerhand von anderen System fort geführt. Im Grund reicht es auch schon mehrere öffentliche IPs zu nutzen.

Zudem, je nachdem wie die iptsables Regeln implementiet werden bedeuten diese ggf. für den Rest des Traffic eine Unterbrechcung und somit Störung im Netzwerkverkehr oder, der Angreifer hält eine Verbindung so lange aufrecht, wie er den angriff durchführen möchte.

Es hängt stark davon ab, wie der Angreifer vor geht und fail2ban die Regeln umsetzt.
Trotz angebliches Sperren von IPs laut fail2ban konnte ich vereinzelt Zugriff und weitere Angriffe von der besagten IP auf den Dienst erkennen.

Für das Verständnis ist wichtig zu wissen, dass fail2ban nur reaktiv auf Angriffe / also passiv aggiert.
Damit ist ein Angriff grundsätzlich immer erfolgreich möglich, bevor die vermeindliche Absicherung wirkt.

Vielen Dank für Eure vielen Infos und Tip.

Okay die Repros lass ich dann mal auf Standard und installier was sein muss manuell.

ClamAV: Das Problem des clamd das er zuviel speicher verbraucht ist mir bekannt vom alten Debian System

fail2ban: ja das es keine 100% Sicherheit bietet ist mir klar, ich hatte es bis dato immer dazu eingesezt (auf Testsystem)
das ich nach erhalt der meldung von fail2ban die IP ranges via iptables gesperrt hatte.

Also fail2ban nicht asl Dauerschutz nutzte eher als "info/reporting tool wenn man das so bezeichnen kann

postgrey: okay das hatte ich nicht auf dem Schirm wobei die Menge an Spam schon durch DNSBlacklists eingeschränkt wurde/wird
muss ich mir mal die logs vom alten System zugemüte führen wenns keinen Sinn macht bleibts weg :-)

logwatch: okay hast Du recht dann lassen wir das mal mit dem Repros und machen es von Hand

Nachtrag wegen fail2ban stimmt es sieht nix (fast nix) denn das s.u. hat es nicht mitbekommen keine Info über den Versuchten zugriff

Auszug auf logwatch:

Authentication Failures:
unknown (xxxxxxxx.stratoserver.net): 39 Time(s)
unknown (static.xx.xx.xx.xx.clients.your-server.de): 6 Time(s)

Illegal users from:
xx.xx.xxx.xxx (static.xxx.xx.xx.x.clients.your-server.de): 6 times
xx.xxx.xxx.xxx (xxxxxx.stratoserver.net): 39 times

Entsprechend müsstest Du zum einen die Regexp anpassen, so dass er es erkennt und zum anderen natürlich Actions definieren, was er machen soll. Dir z.B. eine Email senden.

Zur Auswertung wäre wohl jedes Loganalyse Tool so z.B. logwatch besser geeignet.

okay, in dem Thema hab ich mich hier noch nicht beschäftigt da ich Fail2Ban unter Debian gut im griff hatte.

Was mir aber gestern noch aufgefallen ist ist folgendes wenn ich bei iptables die LOGGING funktion aktivert habe:

iptables -N LOGGING
iptables -I INPUT 7 -j LOGGING
iptables -A LOGGING -m limit --limit 10/min -j LOG --log-prefix "DROP: " --log-level 7
iptables -A LOGGING -j DROP

bei:
iptables -A LOGGING -m limit --limit 10/min -j LOG --log-prefix "DROP: " --log-level 7

kommt das er das so nicht ausführen kann

und sobald ich
iptables -A LOGGING -j DROP

ausgeführt habe war der Server tot ! sprich nur ein HardReboot hat mir wieder einen zugriff ermöglicht.

Wieso denn das ? Will doch nur die abgewiesenen zugriffe protokolieren?

Ohne weitere Angabe der Regel wird nun alles gedropt.
-> Ohne Zusatz von der Source, (Sourceip) wird der chain ja wirklich gesperrt.
iptables -A LOGGING -j DROP macht also nichts anderes als den Traffic über den Chain zu droben.
Vom Loggen weiss der chain ja aktuell nichts.
Iptables unter Debian und CentOS sind nicht identisch.


Für das nächste mal, richtig Dir einen cronjob ein, der z.B. alle 5 Minuten iptables flusht iptables -F z.B.