Posts by de_bonner

    Hallo,


    natürlich nicht :-) Kann den die .xml Datei auch beispielsweise unter autoconfig.der-webcode.de liegen obwohl der Host mail.der-webcode.de lautet, vorausgesetzt ich habe die Domain eingerichtet? Und sind die DNS Einstellungen denn wenigstens soweit korrekt?

    Einen wunderschönen guten Tag,


    ich bin aktuell ein wenig am verzweifeln wegen den Einstellungen für Autodiscover/Autoconfig der automatischen Einstellungen für E-Mail über DNS. Aktuell sehen die Einstellungen wie folgt aus:


    * IN A 0 37.120.183.19
    autoconfig 3600 IN CNAME 10 autoconfig.mail.der-webcode.de.
    86400 IN MX 10 mail.der-webcode.de
    mail 86400 IN A 0 188.68.49.176


    _autodiscover._tcp 3600 IN SRV 0 0 587 mail.der-webcode.de
    _autodiscover._tcp 3600INSRV 00 110 mail.der-webcode.de


    _imap._tcp 3600 IN SRV 0 0 587 mail.der-webcode.de
    _imaps._tcp 3600 IN SRV 0 0 587 mail.der-webcode.de
    _pop3._tcp 3600 IN SRV 0 0 110 mail.der-webcode.de
    _pop3s._tcp 3600 IN SRV 0 0 110 mail.der-webcode.de


    Allerdings zieht sich beispielsweise Thunderbird keine automatische Portkonfiguration und stellt folglich auch nicht auf den Host mail.der-webcode.de um.


    Wie sieht dies bei euch aus?

    Es kann zwar sein, dass der Speicher "eigentlich" überhaupt nicht voll ist, aber durch irgendwas oder irgendjemand die Inodes voll ausgereizt sind. Daher gibt es ja auch immer 5% root-Reserve falls mal das /home Verzeichnis etc. welche zum Anmelden benötigt werden voll sind. Beim Storagespace natürlich nicht relevant aber ein Anhalt.


    Mittels "df -i" kann man sich die Inodes Auslastung anzeigen lassen.

    Ich habe mir das ganze nochmal angeschaut und bitte verbessert mich wenn ich falsch liege. Jetzt einmal abgesehen von state oder conntrack, der Aufbau ist der gleiche, steht bei mir die Stateful Inspection oben. D.h. eine Verbindung wird nur zugelassen wenn diese Established oder Related ist, also keine New.


    Wenn ich also, z.B. ssh Aufbaue und keine aktive Verbindung habe, dann trifft diese Regel nicht zu und es wird an zur ssh Rule gesprungen, die dann ja nur den Status New haben kann, andernfalls würde ja Established/Related zum tragen kommen. Daher muss ich hier gar nicht mit state/conntrack arbeiten, da es nichts anderes, wie bereits erwähnt, sein kann als New. Folglich kann ich bei jeden neuen Rule mit dem Status arbeiten muss es aber nicht?


    Grüße

    Das prüfe ich doch allerdings direkt am Anfang:


    Code
    1. 2 2617 283K ACCEPT all -- eth0 * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
    2. 3 144 DROP tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x17/0x02 state NEW
    3. 4 26 1196 MYDROP all -- eth0 * 0.0.0.0/0 0.0.0.0/0 state INVALID
    4. 5 0 0 ACCEPT all -- eth0:1 * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
    5. 6 0 0 DROP tcp -- eth0:1 * 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x17/0x02 state NEW
    6. 7 0 0 MYDROP all -- eth0:1 * 0.0.0.0/0 0.0.0.0/0 state INVALID
    7. 8 0 0 MYDROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID


    Eigentlich sollte doch hier erst einmal jede Verbindung durch müssen, damit nachfolgende Regeln greifen.


    Wie sieht den der iptables Befehl für Dein Beispiel aus?

    Mit nmap 7.0 (nmap -p 1-65535 -T4 -A -v 37.120.183.x) unter Windows 10 erhalte ich folgende Ausgabe:


    Code
    1. [...]Scanning 37.120.183.x [65535 ports]
    2. Discovered open port 80/tcp on 37.120.183.x
    3. Discovered open port 21/tcp on 37.120.183.x
    4. Discovered open port 443/tcp on 37.120.183.x
    5. Discovered open port 8080/tcp on 37.120.183.x[...]


    Allerdings mit nmap 6.40 von einem vServer erhalte ich ein ganz anderes Bild, welches auch viel detaillierter ist und auch dem entspricht was ich in den iptables definiert habe:



    Jetzt bin ich wirklich überfragt. Liegt es vielleicht daran, dass ich mit Windows über WLAN den nmap Scan starte?

    Einen wunderschönen guten Tag,


    ich habe aktuell einen Root-Server auf KVM Basis (sind ja alle) und eine zweite ipv4 Adresse erhalten:



    In der /etc/Network/Interfaces ist es wie folgt definiert:



    Wenn ich jetzt beide IP-Adressen mit NMAP scanne, dann ist bei der ursprünglich zugewiesenen IP-Adresse (eth0) alles dicht, bei der zusätzlichen IP-Adresse (eth0:1) zeigt er mir mehrere offenen Ports an.
    Hier einmal meine iptables Konfiguration:



    Ich komme leider aktuell nicht mehr weiter, stehe Gedanklich ein wenig auf der Leitung. Warum zeigt mit nmap 37.120.183.x mit offenen Ports und 188.68.49.x nur mit den freigegebenen Ports an? Wenn ich das richtig verstanden habe, ist eth0:1 nur eine virtuelle Netzwerkkarte. Muss ich diesbezüglich in iptables anders rangehen?


    Grüße