Beiträge von mainziman

    Verschwörung :D

    im Log meiner Firewall finde ich kiloweise, daß meinem Win10 verweigert wird eine bestimmte IPv4 per HTTPS zu erreichen;

    lt. https://dnslytics.com/ip/40.90.137.120 ist des aber ein Hobel der weder auf Port 80 (HTTP) noch auf Port 443 (HTTPS) reagiert ...

    was pfuschen Billy Boys Erben da?

    ein

    Code
    echo |\                                                                                                                     
      openssl s_client -connect 40.90.137.120:443 2>&1 |\                                                                  
        sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' |\                                                                 
          openssl x509 -text

    wartet ewig und 3 Tage ...

    vor allem interessant wäre beim Unterschied zwischen 100 Mbps und 1000 Mbps folgendes

    merkt man es tatsächlich?

    (außer bei expliziten Downloads)

    sind auch die Latenzen kürzer geworden?

    (bei Latenzen a la 9600 Baud macht es nur wenig Sinn)

    und was ein zusätzliches Qualitätsmerkmal wäre:

    wie dynamisch sind die IP Adressen?

    wuerde es den Sicherheitsgewinn nicht drastisch erhöhen, in der IPtables die Default Policy auf DROP zu setzen zum einem

    (das erfordert evtl. ein paar zusätzliche Regeln)

    und in Bezug auf Port 22 diesen nur von definierten IPs zu erlauben, und im Falle von dyn. IPs sich einfach einen HE IPv6 Tunnel od. so zu besorgen

    um auf die Art eine fixe IP zu haben, dann kann man sich den Aufwand irgendwas einzupflegen, das nicht zu Standardbordmittel gehört und beim nächsten Update

    sehr wahrscheinlich nicht mehr klappt, komplett sparen;

    ich habe es zum Teil so, bei IPv6 mein HE-IPv6-Tunnel, mein ISP ist immer noch IPv4only;

    und bei IPv4 habe ich das da im iptables file

    Code
    -A INPUT -i eth0 -s rangeISP1 -m limit --limit 1/min -m tcp -p tcp --dport 22 -m state --state NEW -j ACCEPT
    -A INPUT -i eth0 -s rangeISP2 -m limit --limit 1/min -m tcp -p tcp --dport 22 -m state --state NEW -j ACCEPT
    ...
    -A INPUT -i eth0 -m tcp -p tcp --dport 22 -m state --state NEW -j DROP

    und Zugriffsversuche durch andere Kunden des selben ISPs enden mit einer abuse-Nachricht an den ISP, von daher nicht das Problem;

    ein Gedanke, wenn man es etwas ausgefuchst, und etwas tricky haben will, ohne irgendwie in die Standard-Boardmittel einzugreifen;

    einfach ein cronjob, welcher z.B. alle 2 Minuten, den dyndns-Namen abfrägt, und im Falle dass die IP eine andere ist,

    einfach folgendes macht

    Code
    iptables -D INPUT -i eth0 -s alteIP -m tcp -p tcp --dport 22 -m state --state NEW -j ACCEPT
    iptables -I INPUT -i eth0 -s neueIP -m tcp -p tcp --dport 22 -m state --state NEW -j ACCEPT

    auf keinen Fall auf den Gedanken kommen, vom heimischen Router aus per wget/curl was am Server aufzurufen - egal ob per SSL/TLS od. nicht und auch egal ob passwortgesichert od. nicht - um so die Firewall von 'innen' zu ändern um Zugriff zu erlangen; ;)

    tldev hab die Lsg. gefunden

    die Linux-VMs haben die open-vm-tools installiert, und da gibts im Verz.

    /etc/vmware-tools/scripts/vmware/ die Mglkt beim Suspend was zu machen und beim Resume was zu machen

    beim Suspend macht er das

    Code
    suspendCaches() {
     toumount=$(mount |grep \/mnt |grep -v \mnt\/data |awk '{ print $3; }')
     for mtpoint in "$toumount";
     do
       umount $mtpoint
     done
    }

    beim Resume das

    Code
    resumeHostDrive() {
     mount /mnt/hostroot
    }

    /mnt/data ist einfach ein 2ter vmdk, und falls ich da mehr gemountet hätte wird das sauber getrennt

    gibts was weniger unorthodoxes als awk '{ print $3; }' ?

    Nachtrag: ich habs gerade entdeckt,

    autofs könnte es lösen;

    ein unmount vor dem Suspendieren der VM bzw. ein shutdown der einen VM wäre wahrscheinlich die einfachere Lsg.;

    whoami0501 ich dachte ein Debian mit einem Froxlor, das ich instinktiv platt mache ;)

    mal was anderes ...

    was sollte das erwartete Verhalten sein, wenn man eine Linux-VM, welche

    per SMB eine Verbindung zu einem z.B. Win10 offen hat, in den Suspend-to-Disk schickt

    und irgendwann später wieder wieder aufweckt in Bezug zur offenen Verbindung sein?

    seit ich meinen Rechner von WinXP zu Win10 migriert habe, dabei die Linux-VMs übernommen habe,

    habe ich mit der einen Linux-VM welche eine SMB-Verbundung zum Rechner selbst hat, Probleme dahingehend,

    dass nach dem Aufwecken dieser Linux-VM die offene Verbindung nicht mehr funktioniert, und hier

    ein restart der VM das behebt; ein umount/mount wäre wahrscheinlich hinreichend, habe in der

    /etc/fstab folgenden Eintrag, da ich diesen Zugriff in der VM immer brauche;

    Code
    //<IPv4-vom-Host>/ROOT$     /mnt/wkst.adm/_root     cifs    credentials=/root/.smbcredentials,uid=0,gid=0,ro,auto,suid,noserverino,dir_mode=0755,file_mode=0644   0 0                                                                                           

    /root/,smbcredentials beinhalten UserId+Password eines Users vom Host selbst

    Zusatzfrage: wäre hier an Stelle von <IPv4-vom-Host> auch der DNS-Name oder die IPv6-Adresse möglich?

    die Linux-VM hat sich nicht verändert, aber der Host (Win10 an Stelle von WinXP bzw. neueres VMware-Release)

    Das ja, daran ist es auch aufgefallen. Aber der Text passt.

    ja das traurige ist hier eigentlich, dass es Mechanismen gäbe die sowas gleich im Keim erstickt,

    aber dessen Verbreitung ist kaum gegeben ...

    Mails müssen nicht verschlüsselt sein, digital signiert würde schon reichen ...