Closed klismoid closed 5 years ago
ettercap -Tq -i eth0 -M arp: remote /192.168.1.1// /192.168.1.3//
There is a space somewhere in your command when there shouldn't.
Hint: it's not the one between -M
and arp
. ;-)
Hi. It is between the : and the "remote"... I think that this time I put the space but not the others of the 100 times that I tried. The arpspoof also does not work (the poisoned machine loses internet connection). Is it possible that this problem is happening because I am using kali on a VM ?
Moon: no scripts were specified, not starting up!
I have no idea where this output is coming from. I'd suggest to uninstall ettercap and download and build it from Source (GitHub). To me it looks like you have a little modified version. What could also help when you dump the packets while the issue occurs using the -w switch.
Yes... I will try using the dhcp instead of arp remote, then try to uninstall and reinstall ettercap from github, then try in another net and then install kali directly on the computer... not using a VM...
Reopening. Sorry about that. Running ettercap inside a VM shouldn't make a difference if you set everything up correctly. It shouldn't hurt though if you run it natively and see if problem still exists.
And for the future: Please be as detailed as possible when reporting issues. Specifying the name and version of your Host OS, Guest OS and all other apps and tools used when facing the issue goes a long way. And if you can, please use the appropriate terminology when discribing what happened. "the internet connection" for example is too vague and not very helpful.
Good luck.
Reopening. Sorry about that. Running ettercap inside a VM shouldn't make a difference if you set everything up correctly. It shouldn't hurt though if you run it natively and see if problem still exists.
And for the future: Please be as detailed as possible when reporting issues. Specifying the name and version of your Host OS, Guest OS and all other apps and tools used when facing the issue goes a long way. And if you can, please use the appropriate terminology when discribing what happened. "the internet connection" for example is too vague and not very helpful.
Good luck.
Ok. I will try to do that. I'm sorry.
I have no idea where this output is coming from. I'd suggest to uninstall ettercap and download and build it from Source (GitHub). To me it looks like you have a little modified version. What could also help when you dump the packets while the issue occurs using the -w switch.
I uninstalled the ettercap and now I'm trying to install from the source and there is other problem haha. In the INSTALL document, the way to install is this : The easiest way:
$ mkdir build $ cd build $ cmake ../ $ make $ make install
When I make "cmake .//" it appears :
root@kali:~/ettercap/build# cmake .// CMake Error at cmake/Modules/FindGTK3.cmake:365 (message): Could not find GTK3 include directory Call Stack (most recent call first): cmake/Modules/EttercapLibCheck.cmake:53 (find_package) CMakeLists.txt:106 (include)
-- Configuring incomplete, errors occurred!
And now I don't know what to do to continue this installation.
You need quite a number of -dev library packages installed as they are dependencies for building. The README contains a call to apt-get (I don't know on which package manager Kali is based on). Start readin from "R E Q U I R E D L I B R A R I E S" That should install 98%. Maybe 100%. When building, right away configure with Debug mesages enabled (just required for troubleshooting). So the sequence would be:
sudo apt-get install debhelper bison check cmake flex ghostscript libbsd-dev \
libcurl4-openssl-dev libgeoip-dev libltdl-dev libluajit-5.1-dev \
libncurses5-dev libnet1-dev libpcap-dev libpcre3-dev libssl-dev \
libgtk-3-dev libgtk2.0-dev
cmake -DCMAKE_BUILD_TYPE=Debug ..
make
sudo make install
Edit: Maybe package names sligntly differ. Try to find the right one by searching the package repository (differs depending on the distribution).
You need quite a number of -dev library packages installed as they are dependencies for building. The README contains a call to apt-get (I don't know on which package manager Kali is based on). Start readin from "R E Q U I R E D L I B R A R I E S" That should install 98%. Maybe 100%. When building, right away configure with Debug mesages enabled (just required for troubleshooting). So the sequence would be:
sudo apt-get install debhelper bison check cmake flex ghostscript libbsd-dev \ libcurl4-openssl-dev libgeoip-dev libltdl-dev libluajit-5.1-dev \ libncurses5-dev libnet1-dev libpcap-dev libpcre3-dev libssl-dev \ libgtk-3-dev libgtk2.0-dev cmake -DCMAKE_BUILD_TYPE=Debug .. make sudo make install
Edit: Maybe package names sligntly differ. Try to find the right one by searching the package repository (differs depending on the distribution).
Thanks koeppea ! I installed these and other 2 more libraries and the cmake worked and I installed the ettercap ! But it made no difference. The problem is the same... When I try arp or dhcp spoofing (using arpspoof, ettercap or mitmf) nothing happens; the only thing is that the targets lose connection with Internet (Connection Timed Out) and nothing is captured by ettercap or mitmf.... Maybe the local network where my devices are connected has some protection against spoofing.. I don't know... I have Kali as Guest OS, Windows 10 as Host OS, Windows 7 as Guest OS and other notebook with Windows 8... The interesting is that the MITMf worked (arp and dhcp spoofing) against the machine with Win7 and this machine is the only one that does not lose connection with Internet when is target for arpspoofing and ettercap. When I tried ettercap -Tq -i eth0 -M arp:remote /192.168.1.1// /192.168.1.20// athough windows 7 has not lost connection to the internet, the ettercap did not present any results; I accessed websites normally, nothing came up about site's certificate, I typed logins and passwords, and the ettercap did not capture anything. Only with the MITMf credentials were captured in windows 7 (but not in any of the others....) I will give up trying to do all this on this local network and will try on others to test if it works.
I just get kinda upset because I do not know what the problem is ... if it's something on my hardware ... if it's that local network that has something .... if it's something about VMs ... or in the software...
Do kali and win7 shared some kind of internal virtual network connection? Is IP forwarding enabled? Can you upload your ettercap_debug.log file?
You're frustrated because you don't know how to troubleshoot the issue. It could be that your test network has some kind of protection against this, but until you learn how to or isolate the issue, you'll be tapping in the dark.
Use ping
to check if the boxes can reach each other and run arp -a
on
win8 to see if poisoning has any effect (It must have since you're causing
a DOS).
Ettercap also has some plug-ins that can help you. Autoadd may be useful so you don't have to worry setting your targets. And reply_arp to offers a passive approach to arp spoofing.
On Sat, Apr 27, 2019, 6:22 AM klismoid notifications@github.com wrote:
I just get kinda upset because I do not know what the problem is ... if it's something on my hardware ... if it's that local network that has something .... if it's something about VMs ... or in the software...
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/Ettercap/ettercap/issues/938#issuecomment-487250489, or mute the thread https://github.com/notifications/unsubscribe-auth/AB7U4UNZMQI6L6XT3AHCGX3PSPBG3ANCNFSM4HIAAERA .
Right. The ettercap-0.8.2_debug.log
file is very helpful after you started ettercap with the -w packets.pcap
flag in addition. Then please provide the packets.pcap file together with the debug logfile.
This may help to get down to the problem.
Do kali and win7 shared some kind of internal virtual network connection? Is IP forwarding enabled? Can you upload your ettercap_debug.log file? You're frustrated because you don't know how to troubleshoot the issue. It could be that your test network has some kind of protection against this, but until you learn how to or isolate the issue, you'll be tapping in the dark. Use
ping
to check if the boxes can reach each other and runarp -a
on win8 to see if poisoning has any effect (It must have since you're causing a DOS). Ettercap also has some plug-ins that can help you. Autoadd may be useful so you don't have to worry setting your targets. And reply_arp to offers a passive approach to arp spoofing.
I think that kali and win7 did not share any internal virtual network connection. The only thing is that when I was learning how to use the Metasploit I attacked the win7 several times and there is a persistence in the autorun. But I think it makes no difference.... the multi/handler in kali is not even listening... About the IP forward, it is enabled (echo 1 > /proc/sys/net/ipv4/ip_forward). About the "ping" and "arp -a" , in win8 when I ping www.google.com , all the packets are lost. When I ping other device in the network, the packets reaches the destination. The arp-a in win8 shows that the gateway and the kali has the same MAC. I'm going to do now the other things that you suggested and post here the results. One interesting thing is that I have in my cellphone the app FING. Since I used the arpspoof the first time, when I use the FING , this notebook has been appearing as WFADevice (192.168.1.15 + x)... the .15 is the Host OS win10 and the x is the number of VMs that are on . Exemple: if the kali and win7 are on, it appears as 192.168.1.15 + 2 . What I mean is that the router is WFADevice and my systems here are still appearing with the name of the gateway even when I'm not poisoning nothing... It seems that the gateway has not yet forgotten the first poisoning, it is still still considering the name of my notebook as the name of itself (the gateway). I live in a Flat, there is 1 router for each floor, so the network is not "mine". That's why I say maybe it has some protection on the network .... I'm not the admin, so I don't know... Obs.: Sorry about my English. It's not perfect. Thanks !
Right. The
ettercap-0.8.2_debug.log
file is very helpful after you started ettercap with the-w packets.pcap
flag in addition. Then please provide the packets.pcap file together with the debug logfile. This may help to get down to the problem.
Ok. I will do that and post here the results. Thanks !
ettercap-0.8.2_debug.log win8pcap.txt
These are the debug.log and the packets.pcap (in format txt) of the results of target win8 (remembering that this is in my other notebook... not the notebook with the VMs... kali...)
ettercap-0.8.2_debug.log packetswin7pcap.txt The win7 is one Guest OS
I started the other VM Guest (Linux Metasploitable) with the autoadd on. When I tried to ping www.google.com, it worked, with no packet loss. The ettercap showed :
Plugin name (0 to quit): autoadd Activating autoadd plugin...
DHCP: [192.168.1.1] OFFER : 192.168.1.17 255.255.255.0 GW 192.168.1.1 DNS 192.168.1.1 "Home" DHCP: [192.168.1.1] ACK : 192.168.1.17 255.255.255.0 GW 192.168.1.1 DNS 192.168.1.1 "Home"
But is it right the DNS to be the same of the gateway ? I thought it should be one DNS like 8.8.8.8 or other...
That the gateway and the DNS server are the same IP typical. I’ll have a look at the files and revert back.
I just recall w/o having yet looked at the files, that there was another similar issue with poisoning an iPhone.
There activating smart arp poisoning solved the issue. Can you try to activate that in the etter.conf. I think it’s called arp_poison_smart or similar.
Hi koeppea, I activated the arp_poison_smart. When I ran ettercap arp:remote against win8, I used arp -a in win8 and one time the MAC of the gateway is showed as the same as the kali (the internet does not work in win8)... when I use arp -a some seconds latter, the MACs of kali and gateway are different (internet works in win8)... seconds later using arp -a , the MACs are the same again and win8 has no Internet.. arp -a secons later again, the MACs are different and win8 has internet..... and so it goes...
One weird thing is that when I ping www.google.com from the win10 host os (either if the ettercap is poisoning something or turned off ...), the response appears coming from a reserved ip ... not from google .. Pinging www.google.com:
Answer from 127.128.1.16: bytes = 32 time = < 1 ms TTL = 128
@klismoid yes the smart poisoning method has the drawback being less reliable because it tries to be stealthy. This can help on OS'es that have kind of ARP poison detection enabled but on the other hand it increases the risk to loose the race condition when the victim refreshes it's ARP cache.
However the fact that you use addresses from the Loopback network 127.0.0.0/8 tells me, that you're probably have your VM network environment configured as a host-based network. This may be an reason why you're seeing these IP address mix. You simulate a normal network when you're using bridged mode in your VM network environment.
packets.pcap (in format txt)
What does that mean in .txt format? Just the file produced by ettercap would be helpful. Unfortunately the packet capture files cannot be used since Wireshark cannot open them. I'm afraid you've to redo the test and leave the file as it is.
BTW: to improve the smart ARP poisoning you can in addition activate the ARP request poisoning _arp_poisonrequest
Just had a look at the debug log file:
I see that IP forwarding was enabled: disable_ip_forward: old value = 1
.
Ettercap disables it while it's running because Kernel-Based forwerding contradicts the modified forwarding Ettercap takes care to achieve such MITM situations.
What is the reason for having IP forwarding acvitated? Is this machine where Ettercap is running the gateway for the victim machines at the same time?
@klismoid yes the smart poisoning method has the drawback being less reliable because it tries to be stealthy. This can help on OS'es that have kind of ARP poison detection enabled but on the other hand it increases the risk to loose the race condition when the victim refreshes it's ARP cache.
However the fact that you use addresses from the Loopback network 127.0.0.0/8 tells me, that you're probably have your VM network environment configured as a host-based network. This may be an reason why you're seeing these IP address mix. You simulate a normal network when you're using bridged mode in your VM network environment.
Hi @koeppea , in the configuration of the VMs, they are configured in bridged mode. I'm sorry, but which address from the Loopback would be expected if not the 127.0.0.0/8 ? What I think it's strange is that when I ping any host of the Internet, from the win10 host os, the answer comes from the same ip... 127.128.1.16 (reserved IP address). What does it mean ?
This is the ipconfig of the win10....
Configura‡Æo de IP do Windows
Adaptador Ethernet Ethernet:
Estado da m¡dia. . . . . . . . . . . . . . : m¡dia desconectada
Sufixo DNS espec¡fico de conexÆo. . . . . . :
Adaptador Ethernet VirtualBox Host-Only Network:
Sufixo DNS espec¡fico de conexÆo. . . . . . :
Endere‡o IPv6 de link local . . . . . . . . : fe80::4c3a:9392:7105:a0bc%5
Endere‡o IPv4. . . . . . . . . . . . . . . : 192.168.56.1
Máscara de Sub-rede . . . . . . . . . . . . : 255.255.255.0
Gateway PadrÆo. . . . . . . . . . . . . . . :
Adaptador Ethernet Npcap Loopback Adapter:
Sufixo DNS espec¡fico de conexÆo. . . . . . :
Endere‡o IPv6 de link local . . . . . . . . : fe80::5861:194a:3ed0:fad0%10
Endere‡o IPv4 de Configura‡Æo Autom tica. . : 169.254.250.208
Máscara de Sub-rede . . . . . . . . . . . . : 255.255.0.0
Gateway PadrÆo. . . . . . . . . . . . . . . :
Adaptador de Rede sem Fio ConexÆo Local* 1:
Estado da m¡dia. . . . . . . . . . . . . . : m¡dia desconectada
Sufixo DNS espec¡fico de conexÆo. . . . . . :
Adaptador de Rede sem Fio ConexÆo Local* 2:
Estado da m¡dia. . . . . . . . . . . . . . : m¡dia desconectada
Sufixo DNS espec¡fico de conexÆo. . . . . . :
Adaptador de Rede sem Fio Wi-Fi:
Sufixo DNS espec¡fico de conexÆo. . . . . . : Home
Endere‡o IPv6 de link local . . . . . . . . : fe80::cd47:4341:7599:4400%6
Endere‡o IPv4. . . . . . . . . . . . . . . : 192.168.1.15
Máscara de Sub-rede . . . . . . . . . . . . : 255.255.255.0
Gateway PadrÆo. . . . . . . . . . . . . . . : 192.168.1.1
Adaptador Ethernet ConexÆo de Rede Bluetooth:
Estado da m¡dia. . . . . . . . . . . . . . : m¡dia desconectada
Sufixo DNS espec¡fico de conexÆo. . . . . . :
Just had a look at the debug log file: I see that IP forwarding was enabled:
disable_ip_forward: old value = 1
. Ettercap disables it while it's running because Kernel-Based forwerding contradicts the modified forwarding Ettercap takes care to achieve such MITM situations.What is the reason for having IP forwarding acvitated? Is this machine where Ettercap is running the gateway for the victim machines at the same time?
Maybe this time I had set the ip_forward = 1 .... I have been trying in a lot of ways.... ip_forward = 0 .... ip_forward = 1 ....
packets.pcap (in format txt)
What does that mean in .txt format? Just the file produced by ettercap would be helpful. Unfortunately the packet capture files cannot be used since Wireshark cannot open them. I'm afraid you've to redo the test and leave the file as it is.
I tried to send the .pcap file but it was not possible to attach here because of the format not supported....
What I think it's strange is that when I ping any host of the Internet, from the win10 host os, the answer comes from the same ip... 127.128.1.16 (reserved IP address). What does it mean ?
That's right. That's strange. Normally only 127.0.0.1 is being used. Other loopback addresses are only used in very rare cases as far as I known. Therefore it's strange that you receive this answer. However the packet capture file would be interesting.
Maybe your can create a Gist to upload the files: https://help.github.com/en/articles/about-gists
P.S. Have you also tried to activate smart and request poisoning?
Other 2 tests: 1-) ettercap -Tq -i eth0 -M dhcp:192.168.1.150-170/255.255.255.0/8.8.8.8 I started all my devices and only the devices "inside" the VirtualBox were caught by dhcpspoof (win7, metasploitable, android vm, winxp vm) * I reinstalled the winxp vm because it had expired the 30 days of use. My win8, my samsung galaxy and my girlfriend's iphone were not affected.. they kept the "normal" IP address of before.
2) python mitmf.py --hsts -i eth0 --dhcp --spoof --gateway 192.168.1.1 Only the devices inside the VirtualBox were affected (win7, winxp, android and metasploitable) and I could capture credentials when I tried on win7 and winxp.
I think that all the problems that I have been having have any kind of connection with the VirtualBox.. maybe if kali was native...
What I think it's strange is that when I ping any host of the Internet, from the win10 host os, the answer comes from the same ip... 127.128.1.16 (reserved IP address). What does it mean ?
That's right. That's strange. Normally only 127.0.0.1 is being used. Other loopback addresses are only used in very rare cases as far as I known. Therefore it's strange that you receive this answer. However the packet capture file would be interesting.
Maybe your can create a Gist to upload the files: https://help.github.com/en/articles/about-gists
P.S. Have you also tried to activate smart and request poisoning?
Yes, the same.. in the win8 it did not work. I'm going to read and create the Gist. Thanks
maybe if kali was native
Maybe. It's really strange that all addresses resolve to a single address. On Windows there is often the possibility that the antivirus software conflict with the VM. Not with a VM exactly, but with the kernel module it loads to allow bridging. If you have some kind of "advance" net protection feature running, or any kind of other software that uses window's filtering platform, disable it and see if that helps.
Ahhh I discovered what was happening with the ping in win10... I have the software TORIFIER and there were some programs being torified (firefox, netcat, nmap). Now win10 pings normally. I will do all the tests again in kali (ettercap, arpspoof, mitmf) and then I post the results.
No difference....even windows now pinging correctly, arpspoofing does not work against devices that are not the VMs...
We'll need to see the packet capture. If you zip compress it, then you can upload it here.
On Sun, Apr 28, 2019, 7:58 PM klismoid notifications@github.com wrote:
No difference....even windows now pinging correctly, arpspoofing does not work against devices that are not the VMs...
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/Ettercap/ettercap/issues/938#issuecomment-487397022, or mute the thread https://github.com/notifications/unsubscribe-auth/AB7U4UIOFT3NQNV64BCHINDPSXJT7ANCNFSM4HIAAERA .
Here they are..
Thanks. Inspecting...
Hi ! Did you find something important in the packets ?
Following observation from the packet capture files: Win7: It really seems the ARP entry for the gateway is flapping with a high frequency or duplicating packets and sending it to both Layer2 destinations. I see ackloledged packets from Win7 machine arriving at the Ettercap host before Ettercap has transmitted the server packets.
Win8: From the Win8 machine, packets arrive at Ettercap for remote destinations, however the MAC address is not set to Ettercap's host MAC address. It seems Ettercap's host is in the traffic path anyway (e.g. Hypervisor). In case it's a wireless network involved, modern wireless solutions can also prevent ARP spoofing when it tries to minimize the broadcast traffic.
All in all to me it seems your local network is setup in a way that appears to prevent ARP spoofing not to work - either on purpose or by accident.
Hi @koeppea ! Thank you for the analisys !! Actually, the technical part I didn't understand well. But I understood the conclusion. For you, my local network has some kind of prevention against ARP spoofing.
Yesterday I did the same tests in the network of my mother's house. They were in some parts strange hehe.
ARPSPOOF WITH IP FORWARD + DNSSPOOF win7 vm - The Internet worked normally and all the requisitions were shown in Dnsspoof win8 other pc - The Internet worked only for a few sites (hotmail, google, yahoo, fb, instagram..) For the vast majority not. The error was the Connection timed out. Only the few sites could be pinged. Nothing was shown in Dnsspoof terminal.
ETTERCAP - ARP:REMOTE
win7 vm - Internet worked normally, but nothing was shown in the browser about certificates and nothing was shown in Ettercap terminal win 8 other pc - the same of ARPSPOOF (only few sites could be accessed and pinged). Nothing about certificates in browser and nothing in Ettercap's terminal.
I'm thinking that besides the networks maybe have anything against arp spoofing, the ettercap may be with problem. Because even in win7 vm, NOTHING was shown about the certificates (as if there were no ettercap); the MITMf worked more or less in win7 vm....
I don't know what you expected when you talk about certificates in browser.
Form the debug log provided earlier, etter.conf was not set up to intercept SSL. However, don't promise too much, because these days popular websites and browsers are quite well security against SSL interception. To be successful, it must be very sophisticated.
By default Ettercap doesn't intercept SSL. It just forwards the TCP packets.
However when you talk about ARPSPOOF. You mean you use a external tool to do the ARP spoofing?
You'd only let Ettercap take care by using arp:remote MITM. Also don't use IP forward as mentione earlier.
I don't know what you expected when you talk about certificates in browser. Form the debug log provided earlier, etter.conf was not set up to intercept SSL. However, don't promise too much, because these days popular websites and browsers are quite well security against SSL interception. To be successful, it must be very sophisticated. By default Ettercap doesn't intercept SSL. It just forwards the TCP packets. However when you talk about ARPSPOOF. You mean you use a external tool to do the ARP spoofing? You'd only let Ettercap take care by using arp:remote MITM. Also don't use IP forward as mentione earlier.
My objective is to test how to use ettercap to capture logins and passwords. I know that when everything is set correctly, the target opens the browser and accesses the site (for exemple hotmail). Then he types the login and password and sends. I want to see the login and pass in ettercap's screen; and I know that for the "victim" it's going to be shown in the browser about the ettercap's certificate to accept (or not). I have already done it using MITMf (./mitmf.py --hsts -i eth0 --arp --spoof --target 192.168.1.20 --gateway 192.168.1.1). I used win7 vm as victm and IE-8 and Firefox 17.0.1 and it was successfull in some sites.... in others it was not... When I tried in the google chrome (I don't remember the version) it did not work. What I want is to do the same test using the ettercap.
When I talk about ARPSPOOF it's the external tool "arpspoof -i eth0 -t 192.168.1.20 -r 192.168.1.1" with IP forward = 1
The DNSSPOOF is also a external tool "dnsspoof [-i interface] [-f hostsfile] [expression]" I "joined" the arpspoof command above with "dnsspoof -i eth0".
I used dnsspoof just to see the requisitions.
This normally works with ettercap alone.
ARP spoofing is also built in ettercap and should not be combined with other externals tools.
DNS spoofing is available as a plugin. the etter.dns file contains the DNS queries to be spoofed and it's enabled using -Pdns_spoof.
To intercept SSL you need to set the UID to 0 and uncomment the correct iptables redir_commands in etter.conf.
But it's still not clear to me why your targets behave that way even though ettercap sends the poisoned ARP packets correctly.
This normally works with ettercap alone. ARP spoofing is also built in ettercap and should not be combined with other externals tools. DNS spoofing is available as a plugin. the etter.dns file contains the DNS queries to be spoofed and it's enabled using -Pdns_spoof. To intercept SSL you need to set the UID to 0 and uncomment the correct iptables redir_commands in etter.conf. But it's still not clear to me why your targets behave that way even though ettercap sends the poisoned ARP packets correctly.
Hi @koeppea . I'm sorry. Maybe I did not express myself well. When I talked about arpspoof and dnsspoof as external tools , it was other thing, with no connection to ettercap. I wanted just show that doing the arpspoof with other tools (besides the ettercap) was not working too. Yes, it works with ettercap alone. Ahh Thank you. I will try to do what you said about the SSL interception in etter.conf.
"But it's still not clear to me why your targets behave that way even though ettercap sends the poisoned ARP packets correctly." For you it's because there is something in the network preventing the arpspoofing, right ?
For you it's because there is something in the network preventing the arpspoofing, right ?
Right.
Hi @koeppea ! Now I have Kali native. I installed the lastest version. It seems that the arp poisoning is working now. The other machines and devices are not losing the internet connection anymore. You said : "To intercept SSL you need to set the UID to 0 and uncomment the correct iptables redir_commands in etter.conf."
These are the correct iptables redir_commands :
redir_command_on = "iptables -t nat -A PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport" redir_command_off = "iptables -t nat -D PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"
Sorry, but I don't know with which parameters to fill it. Maybe "wlan0" after the "-i"... and the ports ? "--dport" and "--to-port" ?? I saw in other issues people who put "--dport 80" and "--to-port 10000"... Why 10000 ?
Do i know how to do that ?
Keep the variables as they are. Just uncomment the appropriate commands. The variables are replaced by ettercap during startup.
Thanks @koeppea !!
Closing.
Hi,
I have gone through the entire discussion here as i have been facing the same problem with ettercap / arpspoof/ mitmf that when the arp-spoofing is ON, the target is loosing the internet connection. BUt i could not figure out the actual solution. Would earnestly request you to please help me and guide.
Hi,
I'm having trouble using Ettercap. I run the command "ettercap -Tq -i eth0 -M arp: remote /192.168.1.1// /192.168.1.3//", apparently in the terminal of ettercap everything worked fine but the poisoned machine loses the connection to the internet (connection timed out) and on the screen of the ettercap does not appear anything else. I've already tried to enable global routing (echo 1> / proc / sys / net / ipv4 / ip_forward) but it made no difference. Just when I disconnect the ettercap, the internet connection returns to the poisoned machine. The same happens when I do the "arpspoof" command.
Ettercap screen:
root @ kali: / proc / sys / net / ipv6 / conf / eth0 # ettercap -Tq -i eth0 -M arp: remote /192.168.1.1// /192.168.1.3//
ettercap 0.8.2 copyright 2001-2015 Ettercap Development Team
Listening on: eth0 -> 08: 00: 27: C2: E9: BC 192.168.1.16/255.255.255.0 fe80 :: a00: 27ff: fec2: e9bc / 64
SSL dissection needs a valid 'redir_command_on' script in the etter.conf file Privileges dropped to EUID 65534 EGID 65534 ...
33 plugins 42 protocol dissectors 57 ports monitored 20388 mac vendor fingerprint 1766 tcp OS fingerprint 2182 known services Moon: no scripts were specified, not starting up!
Scanning for merged targets (2 hosts) ...
3 hosts added to the hosts list ...
ARP poisoning victims:
GROUP 1: 192.168.1.1 18: 62: 2C: CB: F6: 37
GROUP 2: 192.168.1.3 5C: 51: 4F: 58: E4: 31 Starting Unified sniffing ...
Text only Interface activated ... Hit 'h' for inline help
Can someone help me ?
Thank you, Carlos