15.12.2015 09:27
Szenario QEmu-Host Hack?
Gerade VM-Hostrechner drüften anfällig sein für eien Attacke bei welcher
ein Kunde dem anderen Kudnen auf der Bridge vortäuscht ein
von extern ankommendes Netz zu sein. Man würde etwa auf eien rt Loopback
Adapter den ebide gemeinsm mit dem Host verwenden, (bridge),
einfach neue Adressen aufrouten. Um sowas zu überprüfen müsste an
die Latenzen der möglicherweise gespooften IPs mit den per Traceroute
ermittelten Werten vergleichen.
Typischer DDOS : gefakte Anfrage mit wenig Traffic eingehend verursacht
viel Traffic/Last ausgehend das Ergebnis wird dann demgefäslchten
Abender zusgtellt der gar keien Anfrage gestellt hatte.
Ein Shared host bei dem an an den IPs rumspieln kann beiet sich für eien
soclhen Angriff an. Wer dei Vps betreibt kann man per Trascroute
herausfinden dunsich dort auf dem selben Qemu Serevre gezilet einmieten
auf dem das Opfer sitzt.
NUR MAL SO ALS SZENARIO!
Man darf nämlich nicht einfach so von ner FIRMA1 in ne FIRMA2 umfirmieren
wenn der andere Haupstgesellschafter nicht damit einvestanden ist, die
Kunden mitnehemn, den restlichen Kudnen kündigendas produktive Geschäft
was Gled bringt in die eine Firma überführen und die ganzen Kosten die
man nicht mehr haben will in die anderedie man dann pleiet egehn lässt
wie J*** M***** und M****** G**** das seinrezit vorhatten.
Und mich intersssiert auch brennend warum genau die nicht upgedtete
Internet-Epxlorer verson 5.X genau einspezeillr build derhenige ist bei
dem das Multiform-File-Upload beshcädigt ist. (Funktionie auf ejdem
windows nur nicht bauf der spezeill sabotierten verisondes Abnehmers)
Das ist Sabotage.
~~~
Das ist ne VPS also ein shared Host
hurricane-electric - ja nun nicht der kleinste Anbieter im Internet -
gibt mir aber eine etwa 50/50 aufteilung meines traffics zwischen den
peers an.
http://bgp.he.net/AS21158
I Frankfurt laufen von 30 bis 100GB Traffic auf in Duesseldorf soll es
aber deutlich mehr sein. Erwartunsgemäß würde man jetzt sagen daß in
Düsseldorf in etwa genausviele aufläuft, selbst wenn man sagt daß ich
mit localprefs und so über düesseldorf herausleite wo immer möglich
(weil dort mein inklusiv-trafficpakte größer ist) dürfte das maximal das
doppelte (200 gb/monat) ausmachen was Traffic in 193.109.132.0/23 angeht.
Oder ist das alles Webtraffic auf das Kambach-Interface 194.126.239.78?
Der gar nicht über das 193.109.132.0/23 geroutet ist?
Aber auch das deckt sich nicht mit den Traffic statsitiken eien Hop
weiter in London (DNS-Server) weo teils über 250GB Traffic auflaufen
udn der an beide deustchen Peers angebunden ist.
DAHER:
besteht die thoretische Möglichkeit daß ein andere Kunde auf dem selben
Qemu-Hostrechner Traffic von mir bekommt oder einspielt (auf die
Ether-net-Bridge auf der Proxmox für gewöhnlich läuft?)
Besteht die Möglichkeit mttels der Qemu-Backup-Snapshot Funktion auf das
Filesystem meiner VM zuzugreifen? Das wären nämlich die Unter-schiede
zwischen einem Mietserver wie in Frankfurt und einer VPS wie
in Duesseldorf.
Acuh wer eien DDOS Attacke initiert muss normalerweise seien Traffic
zahelen. Daher wird man sowas möglichst mit gespooften IPs udn möglichst
nahe am anzugreifenden backbone machen.
~~~
Probleme mit Erreichbarkeit von HTTP und DNS
hallo herr .! ich spreche zwo http/dns serverdienste an. einmal in frankfurt und
einmal in duesseldorf. beides über unterschiedliche anbindungen.
die sache in frankfurt ist absolut stabil. duesseldorf bricht immer
wieder zusammen. kann es sein daß irgendjemand port 80tcp oder port
53udp rate-limited oder blockiert? das ist der aufbau mit dem ich die
ipv4s/netze wie vor jahren angekündigt bei bedarf an ehemalige altkunden
per VPN durchreichen will. um die restriktive Firewalls (etwa von
AS1XXX4) zu umgehen per Ethernet in HTTP/DNS Tunneln! Möglicherweise handelt es sich um die Leute die auch gahackte
libc-Mallocs verteilen (Sie erinnern an den Einbruch auf die
Debian-Source-Server?). Ich hab mich schon gewundert als ich für nen
Windows Vierzeiler mal BloodhSed/Dev C++ nutzte warum der - ansonsten
eine Spezialität von uClibc (einer kleinen glibc für embedded systeme) -
keine speicheradresswerte zurueckgab. mal schnell eienen dieser
gratsicompiler nutzte und das realloc nochmal von hand nachprogrammieren
durfte weil es nicht richtig funzte. (workaround, komplett neuen
speicher ind er größeren größe allozieren, memcpy und dann free des
alten Bereichs - dann ein sed s/realloc/reMalloc/g ). Weil der
Äther Shared Medium und dait Bandbreite dort nicht unendlich verfügbar
ist hatten die ihren Traffic überwacht als Filesharing in Mode war als
sogenannten FAIR-USE Traffic und dann stellenweise bei uns angerufen
wenn der Betriebsrat bei einem unserer Nutzer den Napster anwarf was für
mich dann Ärger (Sctuchwort überwchung) gab wenn ich die Info
weitergab. TRACES ergeben AS6805 AS15444 und AS9033 als potentielle Störquellen. von mir nach duesseldorf. root@router:~# traceroute -A 193.109.133.127
traceroute to 193.109.133.127 (193.109.133.127), 30 hops max, 60 byte
packets
1 uplink.eth1.wan (10.10.10.1) [*] 0.779 ms 1.050 ms 2.578 ms
2 rdsl-frnk-de81.nw.mediaways.net (213.20.56.16) [AS6805] 18.708 ms
19.186 ms 19.583 ms
3 bundle-ether21.06.xmwc.99.fra.de.net.telefonica.de (62.53.23.90)
[AS15444] 20.674 ms 21.427 ms 22.593 ms
4 ae11-0.0001.corx.02.fra.de.net.telefonica.de (62.53.26.5) [AS15444]
40.515 ms 40.648 ms ae11-0.0001.corx.01.fra.de.net.telefonica.de
(62.53.26.1) [AS15444] 35.960 ms
5 ae4-0.0001.corx.01.ber.de.net.telefonica.de (62.53.0.60) [AS15444]
37.237 ms ae4-0.0001.corx.02.ber.de.net.telefonica.de (62.53.0.72)
[AS15444] 37.732 ms 39.042 ms
6 bundle-ether12.04.xmwc.99.ber.de.net.telefonica.de (62.53.25.244)
[AS15444] 40.171 ms bundle-ether11.03.xmwc.99.ber.de.net.telefonica.de
(62.53.25.238) [AS15444] 29.057 ms 29.755 ms
7 et-5-3-0-0.0001.prrx.01.ber.de.net.telefonica.de (62.53.11.127)
[AS15444] 26.846 ms 27.387 ms
et-5-1-0-0.0001.prrx.01.ber.de.net.telefonica.de (62.53.11.125)
[AS15444] 29.054 ms
8 e1-20-305.ber.ecix.becrux.hosting-server.cc (194.9.117.8) [AS9033]
41.930 ms 42.488 ms 44.270 ms
9 dns-and-vpn-peer-as64513-dus-dyn-as64516.msd.dynip.name
(193.109.133.127) [AS21158] 45.504 ms 45.765 ms 46.988 ms
root@router:~# von duesseldorf zu mir (dynamische ip - testaufbau in meienr
entwicklungsumgebung auf dem rechner meins bruders zu hause) root@duesseldorf:~# traceroute -A 95.116.207.40
traceroute to 95.116.207.40 (95.116.207.40), 30 hops max, 60 byte packets
1 connectingbytes-kambach.dynip.name (194.126.239.77) [AS34568] 0.695
ms 0.645 ms 0.576 ms
2 tde-deber1.ber.ecix.net (194.9.117.54) [AS9033] 12.722 ms 12.874
ms 12.731 ms
3 hundredgige0-5-0-0.03.xmwc.99.ber.de.net.telefonica.de
(62.53.11.124) [AS15444] 23.803 ms 23.661 ms 23.852 ms
4 ae10-0.0001.corx.01.ber.de.net.telefonica.de (62.53.25.239)
[AS15444] 24.682 ms ae10-0.0001.corx.02.ber.de.net.telefonica.de
(62.53.25.243) [AS15444] 23.164 ms
ae11-0.0001.corx.02.ber.de.net.telefonica.de (62.53.25.245) [AS15444]
23.040 ms
5 ae4-0.0001.corx.01.fra.de.net.telefonica.de (62.53.0.61) [AS15444]
23.284 ms ae4-0.0001.corx.02.fra.de.net.telefonica.de (62.53.0.73)
[AS15444] 23.130 ms 23.200 ms
6 bundle-ether15.06.xmwc.99.fra.de.net.telefonica.de (62.53.26.0)
[AS15444] 24.281 ms bundle-ether16.06.xmwc.99.fra.de.net.telefonica.de
(62.53.26.4) [AS15444] 24.123 ms
bundle-ether15.06.xmwc.99.fra.de.net.telefonica.de (62.53.26.0)
[AS15444] 24.321 ms
7 eth-trunk61.81.rdsl.99.fra.de.net.telefonica.de (62.53.23.91)
[AS15444] 24.413 ms eth-trunk60.81.rdsl.99.fra.de.net.telefonica.de
(62.53.23.89) [AS15444] 42.532 ms 43.810 ms
8 x5f74cf28.dyn.telefonica.de (95.116.207.40) [AS6805] 39.944 ms !X
38.571 ms !X 39.185 ms !X
root@duesseldorf:~#
|
