Sorry for the confusion and delayed response.
Goatboy wrote:You named your filter file "filter.ecf" but in your command you pass in "filter.ef"
Check to make sure you're matching file names. Might have been a typo on the forum when you wrote your post, but it doesn't hurt to make sure. This would make sense because ettercap is doing the ARP poison successfully, but it doesn't have a filter rule so it doesn't know to translate the address to 192.168.2.4 (ATTACKER-SERVER).
I missed out a step here, which is compiling the Ettercap filter file:
- Code: Select all
etterfilter -o filter.ef filter.ecf
In other words, the code I posted is the "source code" for filter.ecf, which is compiled to filter.ef before I can use it with Ettercap.
In any case, I'm quite sure that the packet re-direction by the Ettercap filter was successful, as explained in point (4) of my lengthy post above. Just that, somehow the packet didn't traverse up the network stack to the TCP or application layer.
Just to roll things up a bit,
1. Looking around on the Internet, this doesn't seem to be the way everyone else normally does packet redirection. Nobody else seems to be redirecting packets just by changing the ip.dst field. Seems like the normal way to do redirect packets would be to use iptables in conjunction with Ettercap.
2. So it seems like this is the *wrong* way to do packet redirection with Ettercap. Then I'm curious, from a networking perspective, what's wrong with this approach? The packet that is retransmitted after changing the destination IP field is just as legitimate as any other, so how is it that the packet does reach the host that it is intended for, but does not make its way up to the application?