Beiträge von catfish

    Hi,


    Ich konnte keine Lösung für die Probleme finden trotz ca. 20 Neuinstallationen.
    Der Support konnte mir auch nicht helfen. Hier war der O-Ton "der Server funktioniert doch einwandfrei".
    Ich habe daraufhin den Anbieter gewechselt und bin nun zufrieden.

    Hmm, ich weiß nicht ob es wirklich so eine Erfolgsversprechende Vorgehensweise war 20 mal das gleiche zu machen und dennoch auf ein anderes Ergebnis zu hoffen.

    Wie heise security berichtet findet gerade in Deutschland wieder eine Welle von DDOS-Erpressungsversuchen statt.Hier mal so ein "Erpresserschreiben"


    Hallo,wie sie hoffentlich festgestellt haben, haben wir ihre Webseite für 5 Studen offline genommen. Wir geben ihnen Zeit bis zum 25.10.2014 13:00 Uhr sich bei uns zu melden zwecks Zahlungsvereinbahrung Sollten sie sich nicht melden, sehen wir uns gezwugen, ihre Website fpr längere Zeit offline zu nehmen.Der erste Angriff war nur normaler Syn Flood mit 2% unserer Ressourcen sollten sie sich weigern erhöhen wir unsere Ressourcen gerne.Mfg .

    Es ging mir lediglich darum, an einem konkreten Beispiel aufzuzeigen, daß die Konkurrenz nicht nur nicht schläft, sondern beim Thema Preis/Leistung z.T. schon an netcup vorbeigezogen ist. Allerdings habe ich Hoffnung, daß das nur ein temporärer Zustand ist. Daher bleibe ich vorerst auch selbst netcup-Kunde und vielleicht gibt es ja in Kürze mal wieder ein richtig attraktives Angebot.

    Mal davon abgesehen das dieser Post ja nichts mit dem Sicherheitsproblem zu tun hat. Bei der Auswahl eines ISP's spielen nicht nur Cores und RAM eine Rolle sondern auch I/O Datendurchsatz (oft sehr kritisch bei vielen Anbietern) und die Anbindung an entsprechende Peers (was bringen Dir cores und Ram wenn die Website beim Kunden trotzdem schnarchlahm aufbaut?) sowie Vorschaltung einer hochwertigen, gestaffelten, intelligenten DDOS Firewall (so etwas bieten nur die wenigsten) bis 5 GBits im Standardpaket! (darüber hinaus kann man aber auch mehr anfragen, falls gewünscht).

    DDOS ist mittlerweile die Pest des Internets und kann jeden kleinen bis großen Websitebetreiber einfach wegfegen und was machen die meisten Provider dagegen?Gar nichts oder wenn nur mit extrem teuren Zusatzoptionen die oft teurer sind als der ganze Server.Das Ende vom Lied ist dann oft das der ISP deinen Server selbst abgeknippst, was für den Websitebetreiber genauso einen Totalausfall gleichkommt wie die DDOS-Attacke selbst.Auch empfielt es sich die Vergleichstests zu lesen und da finde ich NC regelmässig unter den besten,oft sogar auf Platz 1 was Preis/Leistung betrifft.Aber jeder so wie er mag :)

    Ich muss mal die NetCup Admins in Schutz nehmen.


    Der Qemu Bug war ziemlich übel. Wenn den jemand ausgenutzt hätte, dann wären eure Systeme nicht nur ein paar Minuten down gewesen sondern vielleicht entgültigt gelöscht und die wertvollen Kundendaten abgegriffen worden (Kreditkartendaten, Anschrift, Bankverbindungen,Telefon,Emails,
    Kennwörter, Hashes die auf andere Webdienste passen, ect) sowie eure Systeme in Spam und Botnet-Zombies verwandelt worden,egal wie sicher Ihr das System konfiguriert habt.Lest euch ruhig mal bei Heise durch was hätte passieren können wenn die Admins hier keine Sonderschicht eingelegt hätten.


    Schwerwiegendes Sicherheitsproblem: CVE-2015-3456
    Da die Lücke im Code des jeweiligen Hypervisors zu finden ist, sind alle Betriebssysteme betroffen, auf denen ein verwundbarer Hypervisor läuft. Für QEMU und Xen sind bereits Sicherheits-Updates verfügbar, die der Admin des Host-Systems einspielen muss ."könnten Angreifer aus einer VM ausbrechen, das Host-System übernehmen und von da aus Daten aus anderen VMs abgreifen."
    Venom-Schwachstelle: Aus Hypervisor ausbrechen und VMs ausspionieren | heise Security

    Das mit den Logs kommt auf die Umgebung an.
    Wenn systemd alles übernimmt und sauber konfiguriert ist, hat eh nur ein Ringspeicher und der kann nicht größer werden als eingestellt :)


    Nutzt ja nun nicht jeder immer und überall Linux oder ein SystemD aktiviertes OS :)
    Bei OpenBSD z.B findet ab einer gewissen größe ein rollover statt.Das ältere Log wird komprimiert und gesichert und ein neues logfile angefangen.Natürlich kann man auch schwellwerte einstellen.Allerdings ändert das nichts daran das von aussen Pakete eintreffen die dann verarbeitet ggf. gedroppt werden müssen und auch das kostet immer CPU/RAM und Bandbreite,was nicht sein muss.

    Hallo,


    Die meisten von euch, die sich mal Ihr authlog von Zeit zu Zeit mal anschauen werden festellen, das gerade aus China und Afrika jede menge SSH Zugriffsversuche eintreffen.Es ist keine Seltenheit dass das log mal schnell 20-30 GBytes groß werden kann, da serienmässig von den Angreifern alle nur denkbaren Usernames/Password Kombinationen durchgetestet werden.Natürlick kann man jede einzelne IP Adresse mittels Firewall aussperren und/oder Fail2Ban installieren, jedoch hält das die Angreifer nicht davon ab es nach ein paar Minuten mit einer neuen IP erneut zu versuchen. Insbesondere ärgerlich ist, das jeder Zugriff protokolliert werden muss,Bandbreite und CPU Zeit frisst und damit die Leistung eures Servers"verbraucht" wird (auch dann wenn mit passphrase und/oder Clientzertifikat und ohne
    username/Password gearbeitet wird) Für die, die schon IPv6 nutzen gibt es einen einfachen Trick, der in der Praxis recht gut funktioniert.Legt euren SSHD einfach auf eine IPv6 Adresse (nicht am Anfang und nicht am Ende eures IPv6 Addressbereichs) sowie auf einen hohen Port.


    Der Aufwand für den Angreifer steigt durch diesen Trick ins unermessliche.Natürlich könnte er einen Rangescan auf euer gesammtes IPv6 Subnet durchführen, sämmtliche Ports pro IPv6 auf SSH Aktivität testen, nur würde das dann ca.100 Jahre dauern bis er auf eine interessante SSHD IPv6 Adresse/Port Kombination stösst (euer IPv6 Subnet hat über 4 Milliarden Addressen).Auch kann es hilfreich sein den SSH Zugriff generell nur für IP's aus Deutschland zu gestatten(wenn klar ist das die SSH User aus Deutschland kommen). Wer mag kann das ganze natürlich noch zusätzlich mit geeigneten Paketfilterregeln und/oder Fail2Ban zusätzlich absichern.


    Catfish

    Hmm, bei mir scheint es auch eine geringfüge Störung nach dem einspielen des Patches zu geben:
    Normalerweise läuft der Server nach einem Neustart, als auch bei einem shutdown -h now und anschliessenden Web-Controlpanel PowerOff sowie PowerOn/Neustart tadelos.Nach dem einspielen des Patch ist IPv6 Konnektivität in Richtung fe80::1 GW jedoch gestört.IPv4 klappt wunderbar aber das IPv6 Gateway macht immer mal wieder sporadische Probleme.

    Allerdings kann ich die Konnektivität wieder selbst herstellen indem ich zunächst alle Routes für IPv6 lösche und die local networksettings
    neu initialisiere:"route flush -inet6; sh /etc/netstart".Danach braucht es noch ein ping6 auf den zuständigen router mittels ff02::2%em0 und nach etwas warten klappt die IPv6 Konnektivität wieder. Kann das eventuell an problematischen Router advertisements liegen?

    Ich finde eher die semi pädagogischen Tipps und den Drang andere permanent belehren zu wollen wesentlich nerviger als ein nicht eingespielter Patch, ein offener Port oder ähnliches.Hier ist ein Communitymitglied und ein treuer Netcupkunde der ein Problem hat und fragt freundlich um Hilfe und zwar zu einem konkreten Sachverhalt.Abgesehen vom Ton, glaube ich nicht das weder der zahlende Kunde noch Netcup es begrüßen wenn Du hier jetzt anfängst jemanden den Server auszureden und sie auf lokale Testinstallationen verweist.Darüber hinaus sieht Netcup in seinem NOC jeden verdächtigen Traffic, informiert den jeweiligen Serverbetreiber im Bedarfsfall per email darüber, schlägt Gegenmaßnamen vor oder schaltet den Server ab wenn das Problem nicht anders zu lösen ist.

    Laut RFC1981
    It is possible that a packetization layer, perhaps a UDP application outside the kernel, is unable to change the size of messages it sends. This may result in a packet size that exceeds the Path MTU.To accommodate such situations, IPv6 defines a mechanism that allows large payloads to be divided into fragments, with each fragment sent in a separate packet (see [IPv6-SPEC] section "Fragment Header").


    File:
    /proc/sys/net/ipv4/route/min_pmtu #default 552, den ggf. mal etwas erhöhen.
    Hinweis:
    Most probably there will be 40 additional bytes for the IP and TCP headers leading to 512 + 20 + 20 = 552.That's Linux's minimum PMTU!

    Du kannst es auch mal probeweise aus/einschalten:
    "echo 0 >/proc/sys/net/ipv4/ip_no_pmtu_disc" => ausschalten
    "echo 1 >/proc/sys/net/ipv4/ip_no_pmtu_disc" => einschalten

    Prüfe mal im Rescue System den Datendurchsatz, wenn der auch schlecht ist musst Du Dich an den Support wenden.Wenn das nicht der Fall ist, dann musst Du Detektiv spielen und schauen welcher Windows Treiber mit der SSD nicht klar kommt.


    Zu Analyszwecken kannst Du ja mal das Windows Performance Toolkit runterladen.
    Download Windows Assessment and Deployment Kit (Windows ADK) for Windows 8.1 Update from Official Microsoft Download Center


    Das Toolkit hat zwei Komponenten:
    1) Performance Recorder. Lass den mal eine Weile aufen und führe die Skripte aus bzw lass die Sachen mit Peformaceproblemen laufen
    2) Wenn Du fertig bist, lade das File in den Peformanceanalyzer und schau Dir die Prozesse an die viel CPU/Memory/IO beanspruchen.

    Auch immer eine Hilfe bei Windows Treiberproblemen: DriverAgent
    Der Scan ist kostenlos und das Ding zeigt Dir zumindest an welche Treiber auf deiner Windowskiste nicht aktuell sind. Wenn z.B der Chipsatztreiber uralt ist kann das schon mal zu unterirdischer Performance führen. Der Test Linux vs. Windows auf dem selben Server wäre auch mal interessant als Vergleichswert oder um zu schauen
    ob es an Windowstreibern oder deinem KVM-System liegt (Hardware).

    So sollte es klappen


    file: global3.min.css
    tag: div.footer { }
    line: 2311 > 2323


    /* current */
    div.footer {
    margin-top: -12px;
    padding: 0 1px;
    background: #245b69;
    background: -webkit-gradient(linear, left top, left bottom, color-stop(0%, #245b69), color-stop(30%, #245b69), color-stop(99%, #002a34));
    background: -webkit-linear-gradient(top, #245b69 0, #245b69 30%, #002a34 99%);
    background: -webkit-linear-gradient(top, #245b69 0, #245b69 30%, #002a34 99%);
    background: linear-gradient(top, #245b69 0, #245b69 30%, #002a34 99%); /* issue */
    filter: progid: DXImageTransform.Microsoft.gradient(startColorstr='#245b69', endColorstr='#002a34', GradientType=0); /* issue */
    font-family: GeoSlb712MdBT, Georgia, serif;
    font-weight: normal

    }


    /* fixed, pass */
    div.footer {
    margin-top: -12px;
    padding: 0 1px;
    background: #245b69;
    background: -webkit-gradient(linear, left top, left bottom, color-stop(0%, #245b69), color-stop(30%, #245b69),
    color-stop(99%, #002a34));
    background: -webkit-linear-gradient(top, #245b69 0, #245b69 30%, #002a34 99%);
    background: -webkit-linear-gradient(top, #245b69 0, #245b69 30%, #002a34 99%);
    background: linear-gradient(to bottom right, #245b69, #000000, #245b69 30%, #002a34 99% ); /* standard css */
    -ms-filter:"progid: DXImageTransform.Microsoft.gradient(startColorstr=#245b69, endColorstr=#002a34', GradientType=0)"; /* pass */
    font-family: GeoSlb712MdBT, Georgia, serif;
    font-weight: normal

    }


    w3c css validator: http://jigsaw.w3.org/css-validator/#validate_by_input

    CSS-"Fehler" sind dank browserspezifischer Hacks (die nun einmal leider oft nötig sind) kaum zu vermeiden.

    Im Konkreten Zusammenhang handelt es sich jedoch nicht darum, siehe Fehlerbeschreibung :


    *Ungültige Nummer : background top ist kein color-Wert
    *Versuche ein Semikolon vor dem Eigenschaftsnamen zu finden. Füge es hinzu.
    *Ungültige Nummer : background top ist kein color-Wert
    *font-family, Georgia,serif: Einlese-Fehler serif;


    Aktuelle Web IDE's wie Jetbrains Webstorm, PhpStorm, Netbeans, ZendStudio als auch VI und Emacs mit den gängigen extensions warnen in der Regel vor derartigen Flüchtigkeitsfehlern.

    v1.6.2 ist z.B. bei Debian die aktuellste Version in den Paketquellen, wieso sollte man da eine neuere einsetzen wollen, wenn es nicht sein muss? :)

    Die 1.6.2-5 Wheezy Distroversion ist schon ok.Allerdings hat Reyk Floeter vom OpenBSD Projekt (der auch hinter den openbsd projekten relayd/httpd steht im bsdnow podcast 53 ein paar Anmerkungen bezueglich NGINX gemacht, warum sie diesen aus dem basesystem entfernt und in die ports collection überführt haben (die keine regelmässige audit durchläuft, so wie das für das basesystem regelmaessig gemacht wird).

    Eine der Hauptgründe war z.B das extrem komplexe Memorymanagement des NGINX-Servers, das viele Routinen des Betriebssystems durch eigene ersetzt(meist aus Performancegründen) und damit wichtige Schutzmechanismen des darunter liegenden OS umgeht bzw. aushebeln kann. Viele Codestellen scheinen ähnlich wie bei OpenSSL organisiert zu sein, wo es ja erst kürzlich mit Heartbleed zu einer gefährlichen Schwachstelle kam. Reyk betont das NGINX auf keinen Fall schlecht ist, aber wegen der Architektur schwer zu auditieren sei und Sicherheitsprobleme daher schwerer zu finden sind. Daher empfielt es sich natürlich mind. die mainline versionen zu installieren (gibt es für viele distros, rhel/centos, debian, suse, ubuntu u.s.w) besonders wenn mann nicht in einer abgeriegelten chroot, jail Umgebung und/oder mit Previllegienseparierung und co. auskommen muss.

    Das soll natürlich wie gesagt kein Nginx bashing sein, das teil ist wirklich cool und für viele Sachen und geschwind wie der Wind :)

    Hallo Herr Preus,


    Hier noch mal meine Kritik:


    #Render-blocking JavaScript and CSS in above-the-fold content
    Solution: Blockende UI Elemente entfernen


    # Optimize CSS Delivery (82% der Ladezeit wird von Bildern verursacht, die noch etwas optimiert werden könnten)
    Solution: Die von Google automatisch optimierten css, Image und Javascript files von hier als Zip-File runterladen und einbinden.

    # Gefunde CSS3-Fehler: 118 Fehler sowie 213 Warnungen, siehe hier
    #JQuery out of Date: 1.9.2 wird verwendet, die aktuelle Version 1.11.3 wird jedoch für den 1.x Branch empfohlen.


    Infos:
    Total HTTP Requests: 38
    Total Size: 2992741 bytes (2,9 MBytes on index page load)
    TOTAL_SIZE - Warning! The total size of this page is 2992741 bytes, which will load in 604.05 seconds on a 56Kbps modem
    Kein SSLv3 protocol support.


    HTTPD: Nginx v 1.6.2, empfohlene Version 1.9.0
    Pragma: no-cache is a request directive, not a response directive.

    Aber ansonsten ist die Seite wirklich sehr professionell gemacht.

    Nun hat die Fragestellung auf der KVM Mailingliste doch noch zu einem Ergebnis geführt, dass ich den anderen interessierten nicht vor enthalten möchte:


    Antwort von: Stefan Hajnoczi - Redhat KVM Entwicklerteam
    The flow is:
    1. Packet is received on physical eth0
    2. Packet is given to software bridge and the destination MAC address is used to determine the bridge port for forwarding.
    3. Packet is forwarded to the tap device on the host that is associated with the guest.
    4. vhost_net reads the packet from the tap device into guest memory and then signals the guest.
    5. Guest notices the received packet and its virtio_net driver hands the packet to the guest network stack.


    All of these components can be swapped out: software bridge vs OpenVSwitch, software bridge vs macvtap, vhost_net vs NIC emulation in QEMU, bridging vs NAT, etc. If you are just learning about this, focus on the one configuration you care about and ignore all others for now. You can use firewall rules on the host on any of the 3 network interfaces (physical eth0, software bridge interface, or tap). If the packets are dropped by the host then the guest will not see them. If the guest relies on its own firewall then packets are transferred into the guest. Once they are inside the guest the host no longer cares about them and they are in guest memory. Whether or not the guest decides to drop them makes no difference to the host.

    Hallo Netcupler :)


    Da die leider sehr allgemein gehaltenen kvm faq's sowie die kaum vorhandene, technische Dokumentation mir meine Fragen nicht beantworten konnte und nach dem selbst auf der kvm maillingliste keiner geantwortet hat (keine Lust, keine Zeit) stelle ich die Frage jetzt einfach mal hier. Hier gibt es ja vielleicht den einen oder anderen QEMU, KVM Experten der da mehr weiß (you never know).


    Das Szenario:
    1)Ein Datenpaket erreicht via Router das KVM-Hostsystem.
    2)Auf dem KVM-Host laufen parallel, mehrere KVM-Gastinstanzen für verschiedene Kunden.
    3)Der Host leitet das Paket an die zuständige KVM-Gastinstanz weiter (z.B Gast e1000 Intel NIC Schnittstelle).
    4)Das KVM-Gast OS beschliesst gemäss Firewallregel das Paket zu droppen.


    Frage:
    *Wo wird dieses Paket nun tatsächlich (physikalisch) verworfen? Am Host oder Gast?
    *Wie lange bleibt der allokierte (malloc) Speicher im Host/Gast-System noch reserviert`und wann erfolgt (free)?
    *Ist das gar kein KVM sondern eher eine QEMU Frage?