Month: January 2017

diese elenden 1&1 wichtel

diese nepper, schlepper, bauernfaenger von 1&1… da surft man auf deren seite rum – mit dem aktuellsten firefox, den es gerade gibt – und dann blenden die einem sowas ein:

und was kriegt man da? einen mit spy-, bloat-, ransom-, wasweissichwas -ware “gepimpten” firefox, der mit sicherheit total verbogen ist und alles was nur geht mit 1&1 vorkonfiguriert hat. bei sowas krieg ich nen hals. haben die es echt noetig, solche methoden anzuwenden? ich rege mich bestimmt gerade nicht das erste mal darueber auf.
aber natuerlich machen die das alles nur im interesse ihrer kunden… is klar.

was tun bei cyberattacken?

linux: die guten alten eth interfaces sind weg

irgendwie trauere ich den alten interface bezeichnungen ja schon nach… eth0, eth1, eth2 usw…

aber es hat auch nen grund, warum das nun u.U. mit 10 stellen dargestellt wird 😉

proxmox: mit firewall ausgesperrt

wenn man die firewall funktionalitaeten bei proxmox nutzt, hat man sich auch mal schnell selbst ausgesperrt, wenn bei der konfiguration z.b. eine gewisse reihenfolge nicht einhaelt 😉

wenn man das bei einem rootserver macht, auf den man keinen physikalischen zugriff hat, wirds bloed. die meisten hoster bieten aber ein rettungssystem an, in das man booten kann. wenn geschehen, muss man sich im rettungssystem seine festplatte mounten – z.b. nach /mnt – und die proxmox firewall ausschalten, so dass sie nach dem booten inaktiv ist.

dazu schreibt man einfach in die datei /mnt/etc/rc.local (sofern die platte nach /mnt gemountet ist)

pve-firewall stop

und nach dem naechste, normalen reboot wird die firewall gestoppt. nicht vergessen, den eintrag wieder raus zu nehmen, wenn alles wieder passt.

hat meine cpu intel vt oder amd-v virtualization support?

unter linux stehen diese informationen in /proc/cpuinfo geschrieben. da dann in einer zeile auch gleich mal >50 sogenannte “flags” stehen, wirds schnell unuebersichtlich.

konkret sind es diese beiden, die uns interessieren koennten:

vmx – Intel VT-x virtualization support enabled in BIOS
svm – AMD SVM virtualization support enabled in BIOS

klar kann man das muehsam durchsehen oder mit “grep –color” den gewuenschten wert farblich hervorheben.. aber irgendwo hab ich mal nen einzeiler gefunden, der das ganze auch noch schick aufbereitet.

egrep -wo 'vmx|svm|lm|aes' /proc/cpuinfo | sort | uniq | sed -e 's/lm/64 bit CPU = Yes (&)/g' -e 's/vmx/Intel VT-x virtualization = Yes (&)/g' -e 's/svm/AMD SVM virtualization = Yes (&)/g'

(den 64 bit support gibts auch gleich mit aus)
das ergebnis schaut z.b. so aus:

now connected with connection lost

Share:
Tagged

lfm: end of the application

aus der reihe “lustige fehlermeldungen” (lfm)

..naja… dabei handelt es sich garnicht um eine felermeldung. egal.

Share:
Tagged

ssh: no kex alg

es kommt doch vor, dass man steinalte linux installation hueten muss.. 😉
wenn der ssh client zu alt ist fuer die ssh server, stolpert man ueber diese meldung:

no kex alg

dann muss man am ende der datei /etc/ssh/sshd_config diese zeile einfuegen und den sshd neu starten:

KexAlgorithms diffie-hellman-group1-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1

das sind alte ciphers, die irgendwann mal standardmaessig bei opsenssh rausgeschmissen wurden und als “potentially-incompatible changes” deklariert sind.

supermicro ipmi board mit ssh tunneln

wenn man mal auf ein IPMI board zugreifen muss und der server nicht direkt, sondern nur ueber einen “hop-server” per ssh erreichbar ist…

ssh root@hophost -L 443:10.11.12.13:443 -L 5900:10.11.12.13:5900 -L 5901:10.11.12.13:5901 -L 5120:10.11.12.13:5120 -L 5123:10.11.12.13:5123 -L 5988:10.11.12.13:5988

in diesem falle handelt es sich um ein AMI-basierten IPMI chip auf einem supermicro board. wenn man noch mehr braucht, wie z.b. das lokale cd-rom durchgeschleift, dann brauchts noch mehr ports. da das remote console gedoense mit java funktioniert, muss man dann noch localhost in den java security einstellungen in die ausnahmeliste hinzufuegen.

openvpn mit systemd

mit systemd ist alles anders… 🙁
hier nur meine notizen dazu.. ohne grosse erklaerung.

cd /etc/openvpn
ln -s server02/server02.ovpn server02.conf

verbindungsaufbau testen:

cd /etc/openvpn
openvpn --config server02.conf

um das dann automatisch starten zu lassen:

cd /lib/systemd/system
ln openvpn@.service openvpn@server02.service

testen…

systemctl start openvpn@server02.service
systemctl status openvpn@server02.service
systemctl stop openvpn@server02.service

wenn alles klappt, bei systemstart auch starten:

systemctl enable openvpn@server02.service