SSL-Verbindung mit sslsniff

Falls ich es mal wieder brauche:

CA und Konsorten erstellen:

CA-Key:
openssl genrsa -aes256 -out ca-key.pem 2048
Root-Cert:
openssl req -x509 -new -nodes -extensions v3_ca -key ca-key.pem -days 1024 -out ca-root.pem -sha512
Zertifikat erstellen:
openssl genrsa -out zertifikat-key.pem 4096
CSR für das Zertifikat:
openssl req -new -key zertifikat-key.pem -out zertifikat.csr -sha512
Beim CN auf den richtigen CN achten
Zertifikat erstellen:
openssl x509 -req -in zertifikat.csr -CA ca-root.pem -CAkey ca-key.pem -CAcreateserial -out zertifikat-pub.pem -days 365 -sha512

IPtables anpassen:
iptables -t nat -A PREROUTING -p tcp –-dport 443 -j REDIRECT –-to-ports 4433
iptables -t nat -A POSTROUTING -p tcp -o eth0 -j MASQUERADE

sslsniff starten:
sslsniff -a -c /root/zertifikat-pub.pem -s 4433 -w /tmp/https.log

Advertisements

OpenVSwitch und VirtualBox

Für meine Tests spiele ich viel mit Virtualbox rum. Um noch etwas flexibler zu sein, habe ich jetzt auf meinem Linux-Notebook OpenVSwitch (OVS) installiert und so konfiguriert, dass VirtualBox (VB) sich mit den Bridges verbinden kann.

sudo ip tuntap add mode tap vnet0
sudo ip link set vnet0 up
sudo ovs-vsctl add-br vbox
sudo ovs-vsctl add-port vbox vnet0
sudo ip link set vbox up

In VB verbinde ich die VM nun einfach mit vnet0.
vnet0 ist irgendwas mit ethX in der VM (zum. bei einer Linux-VM) und erhält dort von mir per
ip addr add 10.0.0.1/24 dev eth0
eine IP.

Auf meinem Notebook mache ich das gleiche, nur mit vbox und ner anderen IP.
An diese OVS-Bridge kann ich nun beliebig viele VMs dranhängen, die alle miteinander kommunizieren können. Die VMs benötigen nur eine vNIC, die am vSwitch angeschlossen ist…

OpenVSwitch virtelle Testumgebung

Um schön mit OVS spielen zu können und alle Features losgelöst von irgendwelchen VMs, Hypervisoren und Konsorten zu testen, helfen die Network Namespaces von iproute2 weiter.
Ein einfaches Szenario zum Testen
host1 OVS host2
lässt sich so realisieren:

ip netns add ns1
ip netns add ns2
ovs-vsctl add-br BRIDGE
ip link add tap1 type veth peer name ovs-tap1
ovs-vsctl add-port BRIDGE ovs-tap1
ip link set tap1 netns ns1
ip netns exec ns1 ip link set dev tap1 up
ip link set dev ovs-tap1 up

ip link add tap2 type veth peer name ovs-tap2
ovs-vsctl add-port BRIDGE ovs-tap2
ip link set tap2 netns ns2
ip netns exec ns2 ip link set dev tap2 up
ip link set dev ovs-tap2 up

per

ip netns exec ns1 bash

wird in den Namespace ns1 gewechselt und es kann nun hin- und her gepingt werden.
Nimmt man ein ovs-tap* aus dem Switch raus, ist die Verbindung weg und nüscht geht mehr…

OpenStack Berechtigungen

Mich hat es Nerven gekostet:
keystone role-list
keystone user-list
keystone tenant-list

Ein User (meist in der entsprechenden conf-Datei hinterlegt) muss auch als keystone user (also in der user-Tabelle in der Keystone-DB) eingetragen sein.
Desweiteren muss es einen Tenant (Container, Mieter,Projekt,???) geben, der Berechtigungen umschreibt (Vllt. sollte ich nochmal lesen, was das Dingen wirklich macht)
Und es muss noch dazu die passende Rolle geben…
am Ende macht ein
keystone user-role-add --user=USERNAME_AUS_CONF --role=ADMIN_ROLLEN_ID --tenant_id=SERVICE_ID
die Möglichkeit, dass ein Service / User sich mit Keystone verbindet…
Normalerweise sollte es daher reichen:
in der conf-Datei:
admin_tenant_id=admin
admin_user=nova
(Oder nen anderen Servicenamen)
Und dann
keystone user-role-add --user nova --role=admin --tenant service