search

droe / sslsplit

Transparent SSL/TLS interception
https://www.roe.ch/SSLsplit
BSD 2-Clause "Simplified" License
1.73k stars 327 forks source link

Failed to lookup target ether, without error from logpkt_ether_lookup #311

Open annadevries1992 opened 1 year ago

annadevries1992 commented 1 year ago

Hello,

When i try to send the log/capt output to a specific IP address which is defined on the local host, it tries for 1 minute and fails with message "Failed to lookup target ether".
But none of the error messages from the logpkt_ether_lookup( show up, so i can't see why it failed.

Any hints on what i'm doing wrong ;-) ?

--

sslsplit -k /root/gw.key -c /root/gw.crt -I ue0 -T 10.1.1.2 -D https 127.0.0.1 8080

SSLsplit 0.5.5-12-ge17de84-dirty (built 2022-08-08) Build info: V:GIT Features: -DDEBUG_OPTS -DDEBUG_PROXY -DHAVE_IPFW -DHAVE_PF NAT engines: pf* ipfw Local process info support: yes (FreeBSD sysctl) compiled against LibreSSL 3.3.6 (20000000) rtlinked against LibreSSL 3.3.6 (20000000) OpenSSL API provided by LibreSSL: LibreSSL 3.3.6 (3030600f) OpenSSL has support for TLS extensions TLS Server Name Indication (SNI) supported OpenSSL is thread-safe with THREADID OpenSSL has no engine support Using SSL_MODE_RELEASE_BUFFERS SSL/TLS protocol availability: tls10 tls11 tls12 SSL/TLS algorithm availability: !SHA0 RSA DSA ECDSA DH ECDH EC OpenSSL option availability: SSL_OP_NO_COMPRESSION SSL_OP_NO_TICKET SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION SSL_OP_TLS_ROLLBACK_BUG compiled against libevent 2.1.12-stable rtlinked against libevent 2.1.12-stable compiled against libnet 1.1.6 rtlinked against libnet 1.1.6 compiled against libpcap n/a rtlinked against libpcap 1.9.1 2 CPU cores detected Generated 2048 bit RSA key for leaf certs. SSL/TLS protocol: negotiate proxyspecs:

-- SSLsplit 0.5.5-12-ge17de84-dirty (built 2022-08-08) Copyright (c) 2009-2019, Daniel Roethlisberger daniel@roe.ch https://www.roe.ch/SSLsplit Build info: V:GIT Features: -DDEBUG_OPTS -DDEBUG_PROXY -DHAVE_IPFW -DHAVE_PF NAT engines: pf* ipfw Local process info support: yes (FreeBSD sysctl) compiled against LibreSSL 3.3.6 (20000000) rtlinked against LibreSSL 3.3.6 (20000000) OpenSSL API provided by LibreSSL: LibreSSL 3.3.6 (3030600f) OpenSSL has support for TLS extensions TLS Server Name Indication (SNI) supported OpenSSL is thread-safe with THREADID OpenSSL has no engine support Using SSL_MODE_RELEASE_BUFFERS SSL/TLS protocol availability: tls10 tls11 tls12 SSL/TLS algorithm availability: !SHA0 RSA DSA ECDSA DH ECDH EC OpenSSL option availability: SSL_OP_NO_COMPRESSION SSL_OP_NO_TICKET SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION SSL_OP_TLS_ROLLBACK_BUG compiled against libevent 2.1.12-stable rtlinked against libevent 2.1.12-stable compiled against libnet 1.1.6 rtlinked against libnet 1.1.6 compiled against libpcap n/a rtlinked against libpcap 1.9.1 2 CPU cores detected

-- FreeBSD 13.1-RELEASE stable/22.7-n250212-a26d6065f1f SMP amd64

sonertari commented 1 year ago

For ether lookup to succeed, 10.1.1.2 must be reachable on ue0. Can you make sure it is:

ping -I ue0 10.1.1.2

annadevries1992 commented 1 year ago

Hi Sonertari,

Thanks for helping out :)

Ping -I , option is only for multicast addresses on FBSD. It doesn't allow a ping to a specific address.

10.1.1.2 is defined as an alias/32 on the ue0 interface. main address is 10.1.1.1/24. And when setting that 10.1.1.1 as -T target in sslsplit, it also fails after trying for 1 minute.

The idea is to feed Suricata via ue0 with decrypted data from user SSL connections. while the actual SSL traffic goes out on interface em0.

annadevries1992 commented 1 year ago

Is there a way to just tell/config sslsplit what the mirror target mac/arp address is ? So it doesn't have to try to look it up.

sonertari commented 1 year ago

You sound like you know what you are doing, but what happens if you use the -S option on FBSD:

ping -S <IPv4 address of ue0> 10.1.1.2

Currently sslsplit does not support an ether address option for mirror targets.

As you can see in logpkt_ether_lookup(), we send arp requests to see if the mirror target is up. I guess we get the ether address of 10.1.1.2 ue0 successfully, because libnet_get_hwaddr() does not error out. So I guess we cannot receive any reply to our arp requests (max 50 tries).

annadevries1992 commented 1 year ago

Trying to find the source of the issue.. Any ideas on, which specific funtion might fail to resolve the needed info, when "logpkt_ether_lookup(" doesn't state an error message itself.

ping -S 10.1.1.1 10.1.1.2

PING 10.1.1.2 (10.1.1.2) from 10.1.1.1: 56 data bytes 64 bytes from 10.1.1.2: icmp_seq=0 ttl=64 time=0.069 ms 64 bytes from 10.1.1.2: icmp_seq=1 ttl=64 time=0.108 ms

arp -an

(10.1.1.2) at 94:10:3e:b8:78:8a on ue0 permanent [ethernet] (10.1.1.1) at 94:10:3e:b8:78:8a on ue0 permanent [ethernet] (10.1.1.6) at 00:15:65:c3:a0:8f on ue0 expires in 1176 seconds [ethernet] (10.1.1.4) at 9c:c7:a6:cb:c8:53 on ue0 expires in 1092 seconds [ethernet] (192.168.4.1) at 00:1d:aa:44:cd:60 on em0 expires in 1181 seconds [ethernet] (192.168.4.2) at a0:b3:cc:2a:ac:58 on em0 permanent [ethernet]

ifconfig -a

em0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 description: Achterhuis options=4802008<VLAN_MTU,WOL_MAGIC,NOMAP> ether a0:b3:cc:2a:ac:58 inet 192.168.4.2 netmask 0xffffff00 broadcast 192.168.4.255 media: Ethernet autoselect (1000baseT ) status: active nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 groups: lo nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> enc0: flags=0<> metric 0 mtu 1536 groups: enc nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> pfsync0: flags=0<> metric 0 mtu 1500 syncpeer: 0.0.0.0 maxupd: 128 defer: off syncok: 1 groups: pfsync pflog0: flags=20100<PROMISC,PPROMISC> metric 0 mtu 33160 groups: pflog ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 description: Voorhuis options=80000 ether 94:10:3e:b8:78:8a inet 10.1.1.1 netmask 0xffffff00 broadcast 10.1.1.255 inet 10.1.1.2 netmask 0xffffffff broadcast 10.1.1.2 media: Ethernet autoselect status: active nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

sonertari commented 1 year ago

Give it to my ignorance, but I don't understand the following lines in the ifconfig output for the ue0 interface:

inet 10.1.1.1 netmask 0xffffff00 broadcast 10.1.1.255 inet 10.1.1.2 netmask 0xffffffff broadcast 10.1.1.2

So, 10.1.1.2 is one of the IP addresses of the ue0 interface itself, which means that you are trying to mirror the packets to the same interface itself. Right? (Yes, we can ping our own IP address.)

The only way I can see logpkt_ether_lookup() can fail without giving any extra info is if the loop at the bottom reaches 50 trials. This means that the logpkt_recv_arp_reply() handler is failing, which also does not give any reasons.

So, I would recommend inserting a couple of debug prints in logpkt_recv_arp_reply() to see why it exits (if we really receive any arp replies at all). And also one more debug print after the do/while loop to confirm my theory that ctx.result is non-zero.

annadevries1992 commented 1 year ago

Thank you for looking into it,! and giving pointers on where to look :) I'll dive into that section and try to add some debugging output to investigate what's going on.

PS. I know it's one odd setup with traffic on one interface :) Am trying to do something funky whereby the traffic will actually flow without going to a real hardware interface, and if it works.. in the end it may be a cool way to get pfsense and opnsense firewall nasty_traffic detection to a far higher level. But.. for now its playing with stuff to figure things out..

On Wed, 10 Aug 2022 11:49:29 -0700 Soner Tari @.***> wrote:

Give it to my ignorance, but I don't understand the following lines in the ifconfig output for the ue0 interface:

inet 10.1.1.1 netmask 0xffffff00 broadcast 10.1.1.255 inet 10.1.1.2 netmask 0xffffffff broadcast 10.1.1.2

So, 10.1.1.2 is one of the IP addresses of the ue0 interface itself, which means that you are trying to mirror the packets to the same interface itself. Right? (Yes, we can ping our own IP address.)

The only way I can see logpkt_ether_lookup() can fail without giving any extra info is if the loop at the bottom reaches 50 trials. This means that the logpkt_recv_arp_reply() handler is failing, which also does not give any reasons.

So, I would recommend inserting a couple of debug prints in logpkt_recv_arp_reply() to see why it exits (if we really receive any arp replies at all). And also one more debug print after the do/while loop to confirm my theory that ctx.result is non-zero.