Beiträge von HAL 9000

    Danke, ich glaub das wars :) Ich habe zwar kein STATE in meinen Regeln, aber LIMIT, ich glaube das hat hier den gleichen Effekt.
    Ich habe jetzt den umgekehrten Weg gewählt: Die Bann-regeln kriegen zusätzlich STATE = NEW,ESTABLISHED,RELATED gesetzt, und daraufhin kriege ich den Fehler zumindest nicht mehr reproduziert. Ich gucke jetzt mal, ob ich in den nächsten Tagen nochmal sowas im Log sehe. Wenn ja melde ich mich.

    Mir fällt da gerade noch ein Problem auf:

    Code
    2012-04-12 01:28:34,310 fail2ban.actions: WARNING [ssh] Ban 123.142.29.76
    2012-04-12 01:28:47,068 fail2ban.actions: WARNING [ssh] 123.142.29.76 already banned
    2012-04-12 01:29:00,084 fail2ban.actions: WARNING [ssh] 123.142.29.76 already banned
    2012-04-12 01:29:12,096 fail2ban.actions: WARNING [ssh] 123.142.29.76 already banned
    2012-04-12 01:29:24,113 fail2ban.actions: WARNING [ssh] 123.142.29.76 already banned
    2012-04-12 01:29:36,127 fail2ban.actions: WARNING [ssh] 123.142.29.76 already banned
    ...


    So ging es dann noch eine ganze Weile weiter, bis 1:46. Ich hab eben ins VCP geschaut, und die Firewallregel steht drin (source IP 123.142.29.76, action DROP, ansonsten alles auf any), aber anscheinend kamen die Verbindungen trotzdem noch durch. Irgendwelche Ideen warum?

    Normalerweise sind die Daten unverschlüsselt, nur fürs Passwort kann svnserve CRAM-MD5. Man kann svnserve auch mit SASL-support bauen, dann kann er auch Daten verschlüsseln, das habe ich selbst aber noch nie benutzt. Ich würde entweder SSH oder WebDAV (apache mit mod_dav_svn) über https nehmen, dann kann man sicher sein, dass wirklich alles verschlüsselt ist.

    Solange dein Mailserver nicht läuft, bleiben ankommende Mails soweit ich weiß in der Queue des Mailservers, von dem sie kommen, hängen. Dieser versucht dann mehrmals über einen längeren Zeitraum (mehrere Tage), die Mail zuzustellen. Wenn es also nicht zu lange dauert, bis dein Mailserver wieder läuft, dann gehen keine Mails verloren. Sie kommen nur mit Verzögerung an.

    apt-get update produziert bei mir zur Zeit das hier:


    Ich habe jetzt einen anderen Mirror statt debian.netcup.net eingetragen, damit geht es. Hat sonst noch jemand das Problem?