Jump to content

putte

Active Members
  • Content Count

    12
  • Joined

  • Last visited

Everything posted by putte

  1. I been away for awhile, but thought about giving this another try. However I think I have been able to poison the network for ICMP packets flow the correct way, should that be a sign that the its correct? I also see DNS packets flow the correct way that they arrive at the attacker and is forwarded to the routers MAC address. But on the way to the router the message is lost (I do not think this is arp related.). Could the router some how detect the packet has been changed? I guess DNS packets are on a higher level, so might some other handling. Can it be something in the iptable? I included my iptable here for the filter. I see there are some rules for icmp, but I don't really understand them so maybe someone else have some ideas about it.Should any of the other tables be intressting? How add rows for logging when a packet is dropped? # iptables -S -v -t filter -P INPUT ACCEPT -c 0 0 -P FORWARD DROP -c 0 0 -P OUTPUT ACCEPT -c 739842 210491875 -N ACCESS_RESTRICTION -N DNSFILTER_DOT -N FUPNP -N INPUT_ICMP -N INPUT_PING -N NSFW -N OVPN -N PControls -N PTCSRVLAN -N PTCSRVWAN -N SECURITY -N default_block -N logaccept -N logdrop -N other2wan -A INPUT -i eth0 -p igmp -c 50949 1630368 -j ACCEPT -A INPUT -p icmp -m icmp --icmp-type 8 -c 1684 1447978 -j INPUT_PING -A INPUT -m state --state RELATED,ESTABLISHED -c 120974268 49466651583 -j ACCEPT -A INPUT -m state --state INVALID -c 8200 402179 -j DROP -A INPUT ! -i br0 -c 9630083 2065897954 -j PTCSRVWAN -A INPUT -i br0 -c 1846556 238209298 -j PTCSRVLAN -A INPUT -i br0 -m state --state NEW -c 1846556 238209298 -j ACCEPT -A INPUT -i lo -m state --state NEW -c 9453218 2054605288 -j ACCEPT -A INPUT -m state --state NEW -c 176865 11292666 -j OVPN -A INPUT -p udp -m udp --sport 67 --dport 68 -c 0 0 -j ACCEPT -A INPUT -p icmp -c 19 760 -j INPUT_ICMP -A INPUT -c 176763 11282633 -j DROP -A FORWARD -d 224.0.0.0/4 -i eth0 -c 0 0 -j ACCEPT -A FORWARD -m state --state RELATED,ESTABLISHED -c 392212832 390647744304 -j ACCEPT -A FORWARD ! -i br0 -o eth0 -c 0 0 -j other2wan -A FORWARD -i br0 -o br0 -c 2 2984 -j ACCEPT -A FORWARD -m state --state INVALID -c 278948 11799305 -j DROP -A FORWARD -c 8323272 531605893 -j NSFW -A FORWARD -i br0 -c 5655858 372797112 -j ACCEPT -A FORWARD -m conntrack --ctstate DNAT -c 2667414 158808781 -j ACCEPT -A FORWARD -m state --state NEW -c 0 0 -j OVPN -A FORWARD -c 0 0 -j DROP -A FUPNP -d 192.168.1.112/32 -p udp -m udp --dport 51291 -c 0 0 -j ACCEPT -A FUPNP -d 192.168.1.112/32 -p udp -m udp --dport 62360 -c 0 0 -j ACCEPT -A FUPNP -d 192.168.1.100/32 -p udp -m udp --dport 54064 -c 0 0 -j ACCEPT -A FUPNP -d 192.168.1.112/32 -p udp -m udp --dport 59379 -c 0 0 -j ACCEPT -A FUPNP -d 192.168.1.112/32 -p udp -m udp --dport 61371 -c 0 0 -j ACCEPT -A FUPNP -d 192.168.1.100/32 -p udp -m udp --dport 63029 -c 0 0 -j ACCEPT -A FUPNP -d 192.168.1.100/32 -p udp -m udp --dport 59900 -c 0 0 -j ACCEPT -A FUPNP -d 192.168.1.212/32 -p udp -m udp --dport 59080 -c 0 0 -j ACCEPT -A FUPNP -d 192.168.1.100/32 -p udp -m udp --dport 61842 -c 0 0 -j ACCEPT -A FUPNP -d 192.168.1.112/32 -p udp -m udp --dport 60106 -c 0 0 -j ACCEPT -A FUPNP -d 192.168.1.212/32 -p udp -m udp --dport 55476 -c 0 0 -j ACCEPT -A FUPNP -d 192.168.1.100/32 -p udp -m udp --dport 56159 -c 0 0 -j ACCEPT -A FUPNP -d 192.168.1.100/32 -p udp -m udp --dport 62212 -c 0 0 -j ACCEPT -A INPUT_ICMP -p icmp -m icmp --icmp-type 8 -c 0 0 -j RETURN -A INPUT_ICMP -p icmp -m icmp --icmp-type 13 -c 19 760 -j RETURN -A INPUT_ICMP -p icmp -c 0 0 -j ACCEPT -A INPUT_PING -i eth0 -p icmp -c 640 38214 -j DROP -A OVPN -i tun11 -c 0 0 -j DROP -A PControls -c 0 0 -j ACCEPT -A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 1/sec -c 0 0 -j RETURN -A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -c 0 0 -j DROP -A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -c 0 0 -j RETURN -A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -c 0 0 -j DROP -A SECURITY -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -c 0 0 -j RETURN -A SECURITY -p icmp -m icmp --icmp-type 8 -c 0 0 -j DROP -A SECURITY -c 0 0 -j RETURN -A logaccept -m state --state NEW -c 0 0 -j LOG --log-prefix "ACCEPT " --log-tcp-sequence --log-tcp-options --log-ip-options -A logaccept -c 0 0 -j ACCEPT -A logdrop -m state --state NEW -c 0 0 -j LOG --log-prefix "DROP " --log-tcp-sequence --log-tcp-options --log-ip-options -A logdrop -c 0 0 -j DROP -A other2wan -i tun+ -c 0 0 -j RETURN -A other2wan -c 0 0 -j DROP
  2. Thanks digininja, for the tips of using ping :). I ping 8.8.8.8 (google) on my mac when it was arp spoofed. I saw the messages on my kali machine and this time I also got a response. I could also see the message when tcpdump the eth0 on the router. However I still don see the dns request in the router. So think the router discard these messages, however I read the tcpdump(or if it was wireshark in some post, so not sure if its true) should read the messages before they are discarded. But at least now I know it's possible to send messages the whole route and back now. But still need to figure out why the messages are lost in the router. I think it could be something with my iptable, but Im to stupid to understand it. or can it be some other feature that control messages? I have also asked this question in asuswrt-merlin forum however not got any response there. So very thank full for all your tips digininja 🙂
  3. I was able to install tcpdump and run it on the router. I also made my test simpler instead of going to a webpage I just tried to do: dig @ns-604.awsdns-11.net forums.hak5.org When I run the above dig command to generate dns request I could see the message in tcpdump on the router using this command: tcpdump -i eth5 port 53 I saw it both when I run it on the mac and kali-pc(no arpspoof involved). However when I started aprspoof (mac and router). It was still possible to send the dns request from the kali-pc. However from mac the message got lost between kali-pc and the router. I never saw it arrive to the eth5 interface on the router. I updated the picture it can be seen here: Here is DNS request 1 in wireshark running on kali (src: mac, dst: kali ) Note that this first line is highlighted. Here is DNS request 2 in wireshark running on kali (src: kali, dst: router ). Note that this second line is highlighted. The last message that is sent to 0C:9D:92 is never seen when I do tcpdump on the router. I have to little knowledge about tcpdump but guess it monitors packets that goes across the interface. So if the DNS request was discarded directly could explain why I didn't see it when running tcpdump -i eth5 port 53 on router. However can't explain why it should been discarded since it works when I do the request when I run dig directly on kali-pc. Any suggestion what could cause this? I will see if I can find any logs where I can see discarded messages or if I can find any other logs to see where the message disappear. Just as info eth5 (wifi 2.4) and eth6 (5Ghz) and eth1-4 is the ports on the router. I didn't know about this before I thought it was only one interface br0, but br0 is the interface for the public wifi.
  4. I have wireshark installed on my Mac(Note it is not a phone any longer it's a mac pro with wireless card), not sure what to look for on it(See picture above). I also have IP forwarding enabled on my KALI machine. My wireless card is Alfa AWUS036AC (it as support for monitor mode also) in the Kali machine. I will try to change the default gateway, I guess that might show what I should expect to see on my KALI machine if routing was working. However I should still like to understand why my messages is lost in the router(or if they are wrong redirected.) Here is how my iptables looks like, not sure if its any help. admin@RT-AC86U-D368:/tmp/home/root# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination INPUT_PING icmp -- anywhere anywhere icmp echo-request ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED DROP all -- anywhere anywhere state INVALID PTCSRVWAN all -- anywhere anywhere PTCSRVLAN all -- anywhere anywhere ACCEPT all -- anywhere anywhere state NEW ACCEPT all -- anywhere anywhere state NEW OVPN all -- anywhere anywhere state NEW ACCEPT udp -- anywhere anywhere udp spt:bootps dpt:bootpc INPUT_ICMP icmp -- anywhere anywhere DROP all -- anywhere anywhere Chain FORWARD (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED other2wan all -- anywhere anywhere ACCEPT all -- anywhere anywhere DROP all -- anywhere anywhere state INVALID NSFW all -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ctstate DNAT OVPN all -- anywhere anywhere state NEW DROP all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain ACCESS_RESTRICTION (0 references) target prot opt source destination Chain DNSFILTER_DOT (0 references) target prot opt source destination Chain FUPNP (0 references) target prot opt source destination Chain INPUT_ICMP (1 references) target prot opt source destination RETURN icmp -- anywhere anywhere icmp echo-request RETURN icmp -- anywhere anywhere icmp timestamp-request ACCEPT icmp -- anywhere anywhere Chain INPUT_PING (1 references) target prot opt source destination DROP icmp -- anywhere anywhere Chain NSFW (1 references) target prot opt source destination Chain OVPN (2 references) target prot opt source destination DROP all -- anywhere anywhere Chain PControls (0 references) target prot opt source destination ACCEPT all -- anywhere anywhere Chain PTCSRVLAN (1 references) target prot opt source destination Chain PTCSRVWAN (1 references) target prot opt source destination Chain SECURITY (0 references) target prot opt source destination RETURN tcp -- anywhere anywhere tcpflags: FIN,SYN,RST,ACK/SYN limit: avg 1/sec burst 5 DROP tcp -- anywhere anywhere tcpflags: FIN,SYN,RST,ACK/SYN RETURN tcp -- anywhere anywhere tcpflags: FIN,SYN,RST,ACK/RST limit: avg 1/sec burst 5 DROP tcp -- anywhere anywhere tcpflags: FIN,SYN,RST,ACK/RST RETURN icmp -- anywhere anywhere icmp echo-request limit: avg 1/sec burst 5 DROP icmp -- anywhere anywhere icmp echo-request RETURN all -- anywhere anywhere Chain default_block (0 references) target prot opt source destination Chain logaccept (0 references) target prot opt source destination LOG all -- anywhere anywhere state NEW LOG level warning tcp-sequence tcp-options ip-options prefix "ACCEPT " ACCEPT all -- anywhere anywhere Chain logdrop (0 references) target prot opt source destination LOG all -- anywhere anywhere state NEW LOG level warning tcp-sequence tcp-options ip-options prefix "DROP " DROP all -- anywhere anywhere Chain other2wan (1 references) target prot opt source destination RETURN all -- anywhere anywhere DROP all -- anywhere anywhere
  5. The thing I want to achieve is too look at the data traffic between my mac (Phone in the real case) to see the communication for games. So for that I need to also spoof the router, but seems like the spoofing part is done. However the problem is the routing of messages in the router that seems to be lost on the way back from public IP or get received out of order. However I can try to setup an internal webserver on the mac and connect with my iphone to it see if the arp spoofing is work for that part(But this I see as a side track).
  6. I was running arpspoof in two separate terminal windows (as almost all tutorial suggest). However I found the -r flag in the man page: flag -r Poison both hosts (host and target) to capture traffic in both directions. (only valid in conjuntion with -t) So much easier to run. I have also manually verified that both arp tables is updated(As in picture). Here is the output from the command: root@kali:~# arpspoof -i wlan0 -t 192.168.1.1 -r 192.168.1.101 0:c0:ca:FF:FF:FF c:9d:92:FF:FF:FF 0806 42: arp reply 192.168.1.101 is-at 0:c0:ca:FF:FF:FF 0:c0:ca:FF:FF:FF b8:e8:56:FF:FF:FF 0806 42: arp reply 192.168.1.1 is-at 0:c0:ca:FF:FF:FF 0:c0:ca:FF:FF:FF c:9d:92:FF:FF:FF 0806 42: arp reply 192.168.1.101 is-at 0:c0:ca:FF:FF:FF 0:c0:ca:FF:FF:FF b8:e8:56:FF:FF:FF 0806 42: arp reply 192.168.1.1 is-at 0:c0:ca:FF:FF:FF I have also read that tutorial(and most other tutorials). I still think my problem is with my router that not forwarding the packet in correct way. Unfortunately I don have another router that I can borrow to test this(Most my friends can not live with out there own router). Any more ideas what I could investigate? Should the output from iptables -L be interesting?
  7. Sorry for late response, my quota of messages run out last day so had to wait one day before able to respond. Here is a picture of my network layout. I changed my phone to a mac instead so it easier to do debugging like run wireshark. Let me know if any more info is needed. I also run wireshark on my Kali linux machine and found that arp was detected duplicated use (but maybe this is expected). I have blanked out the last part of MAC address I also saw this when running wireshark on my Kali linux in the log when I tried to access www.guimp.com(I google smallest page) from my mac: Seems like the message coming back from the router gets out of order. Any idea what could be wrong? Any more information needed? I can also run wireshark on my mac but not sure what to look for there. I should like to run wireshark on my router but not sure it will be able to handle it(But will look into this tomorrow). Any more information that could be useful? Could the iptables be interesting in the router?
  8. I realized now I found wrong picture (sorry about this, I didn't want to take a own print screen since I should need to remove the mac address)😞. The other one look similar, but it's not for the DHCP(My phone get it ip dynamic so it's not in this list). I have tried some more and found when using: arpspoof -i wlan0 -t 192.168.1.1 -r 192.168.1.100 That did also update the arp table in the router(When using arp -a -v, so I might been wrong here before). But still no update in the GUI. I also started wireshark on my computer (the attacker) and saw that the request from the phone was forwarded to the router. The message came directly after the first message. However I could not see any response from the outside for the messages.
  9. Yes, I its Linux based. I found a print screen also how the viewer looks like on the merlin page. This is the page that do not match the when I do: arp -a -v # I run this command on the router(just to make clear).
  10. Yes, and I think the GUI is the mac address it uses for the IP. Since I do not arpspoof the phone the connection is still working. So it seems like the packets is still forwarded by the router on the old MAC address.
  11. What I meant is the MAC address in the ARP table. That is why I wrote I checked it with: arp -a. There I can see its updated but when I check in the router for the IP-address that devices is using in my network I see the MAC address is not updated for that IP (It seems like it dont reflect what is in the arp cache). In the router there is a view called "network view".
  12. I try to do arpspoof -i wlan0 -t 192.168.1.1 192.168.1.100, to my own router. However when I check in the router the MAC address is not updated. Mu router is Asus RT-AC86U (with asuswrt-merlin latest ) I also tried to update it manually using: arp -s <ip> <mac> # on the router When I check with: arp -a i see it updated and set to PERM. However when I check in the router GUI, I still see the old MAC address. The reason I want to do the above is to start the man in the middle attack(in arp spoof was run in different terminals): sysctl -w net.ipv4.ip_forward=1 arpspoof -i wlan0 -t 192.168.1.1 192.168.1.100 arpspoof -i wlan0 -t 192.168.1.100 192.168.1.1 When trying to browse internet on my phone (192.168.1.100) it just the screen just freezes. However I think the problem is that the router MAC is not updated.
×
×
  • Create New...