DoS when mapping on the WAN?

[redxine]

Recently, I've noticed when I run NMAP on WAN addresses, all the sudden my entire network just locks up. Packets get lost and die, and am sometimes forced to do a hard reset of my modem, although other times I can just wait it out or just reset the interface with

ifconfig eth0 down; ifconfig eth0 up

. After a little investigation, I found that almost all the addresses I scan that cause this are from Quest; I have Cox. Any ideas? :(

[Sparda]

Not that you really should be using nmap on the Internet (your ISP could hate you for it), have you tried running the scan slower? Use the -T option with option 0-5 (0 is slowest, 5 is fastest).

[decepticon_eazy_e]

I would guess that you are DoS'ing your own router/modem. There's a finite amount of ram in those devices to hold open connections, if you do a big enough Nmap scan you're probably filling that up too fast.

Narrow your scan a bit. I use (on a windows box) angry IP scanner to get live or "up" ip addresses quickly in a given range and then use that list to scan ports on, instead of just doing a full port scan on thousands of addresses at a time.

[redxine]

That's the thing. I'm only scanning one address, and sometimes it doesen't matter how many ports I scan. i.e. I normally run nmap with -bvq host port (1-1024). It seems as soon as hit hits a certain port, it all shuts down. And i'm pretty sure that nmap is only going one port at a time; nothing very bandwith/connection intensive. Have never had this problem after 3 years with the same modem and router..... Although I am looking into getting a new router and NICs.... [yay gigabit!]

PS: I'll try running a ping on a known network to see at exacty what port it stops on.

[Sparda]

nmap by default will do stuff allot at the same time. try it with -T 0

[digip]

Im just guessing here, but does it only do it when you scan one network, and not others? Sounds like someone at the other end is aware of the pings, either by way ot IDS or other Security software, and did something to protect themself, like sending back packets with you as the source and destination addresses, so you send them to yourself as the bottleneck, causing a DoS against yourself.

Might try running Wireshark while doing the scan and see what is coming back as replies and what specifically causes it. If you can see a packet come in and you reply to it with you as the source, that would indicate to me that someone forged a packet and sent it back to you with you as both the source and destination in the addresses.

[redxine]

It managed to happen this time without running any software. Just happened out of no where. Here's some information I managed to get out of it:

[root@server redxine]# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
From 192.168.1.20 icmp_seq=1 Destination Host Unreachable
From 192.168.1.20 icmp_seq=2 Destination Host Unreachable
From 192.168.1.20 icmp_seq=5 Destination Host Unreachable
From 192.168.1.20 icmp_seq=6 Destination Host Unreachable
^C
--- 192.168.1.1 ping statistics ---
6 packets transmitted, 0 received, +4 errors, 100% packet loss, time 5868ms
pipe 2

[root@server redxine]# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0C:6E:17:68:9F  
          inet addr:192.168.1.20  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:6eff:fe17:689f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:49569 errors:0 dropped:0 overruns:0 frame:0
          TX packets:43527 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:49912484 (47.6 MiB)  TX bytes:6463710 (6.1 MiB)
          Interrupt:19 Base address:0x8800

And shortly after the failure, [on all computers] I recieved a kernel failure:

Kernel failure message 1:
------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:219 dev_watchdog+0xda/0x12d()
Hardware name: System Name
NETDEV WATCHDOG: eth0 (sis900): transmit timed out
Modules linked in: vfat fat usb_storage fuse it87 hwmon_vid hwmon sunrpc iptable_nat nf_nat nf_conntrack_netbios_ns nf_conntrack_ftp ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 p4_clockmod dm_multipath uinput ppdev ns558 gameport floppy bttv videodev v4l1_compat ir_common compat_ioctl32 v4l2_common videobuf_dma_sg videobuf_core pcspkr btcx_risc firewire_ohci serio_raw tveeprom firewire_core crc_itu_t sis900 snd_ca0106 mii snd_rawmidi snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq usblp snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc parport_pc i2c_sis96x parport ata_generic pata_acpi pata_sis sha256_generic cbc aes_i586 aes_generic dm_crypt crypto_blkcipher radeon drm i2c_algo_bit i2c_core [last unloaded: microcode]
Pid: 0, comm: swapper Tainted: G   M      2.6.27.21-170.2.56.fc10.i686 #1
 [<c042db4c>] warn_slowpath+0x69/0x89
 [<c04242fe>] ? enqueue_entity+0x203/0x20b
 [<c0424341>] ? enqueue_task_fair+0x3b/0x3f
 [<c06ab3fc>] ? _spin_lock_irqsave+0x29/0x30
 [<c0422894>] ? __enqueue_entity+0xe3/0xeb
 [<c04242fe>] ? enqueue_entity+0x203/0x20b
 [<c051ebf2>] ? strlcpy+0x17/0x49
 [<c0641f14>] dev_watchdog+0xda/0x12d
 [<c04281ed>] ? try_to_wake_up+0x230/0x23b
 [<c0436439>] run_timer_softirq+0x14b/0x1bb
 [<c0641e3a>] ? dev_watchdog+0x0/0x12d
 [<c0641e3a>] ? dev_watchdog+0x0/0x12d
 [<c043279b>] __do_softirq+0x84/0x109
 [<c0432717>] ? __do_softirq+0x0/0x109
 [<c0406f1c>] do_softirq+0x77/0xdb
 [<c0432402>] irq_exit+0x44/0x83
 [<c04152b1>] smp_apic_timer_interrupt+0x6e/0x7c
 [<c040576d>] apic_timer_interrupt+0x2d/0x34
 [<c041b753>] ? native_safe_halt+0x5/0x7
 [<c040a15d>] default_idle+0x38/0x6a
 [<c0403c61>] cpu_idle+0x101/0x134
 [<c069ae72>] rest_init+0x4e/0x50
 =======================
---[ end trace 955890b62951cfef ]---

My guess is that the router is dying/being_chrooted and expressing it's agony via kernel failures on all it's host machines. [it's a linksys wrt475 with decent security all ways]

Digip: I can't be completely certain, but i'm almost sure that the networks I scanned that caused the error had Quest Cable/DSL, and the platform did not make a difference. And according to the ping I ran, the packets appear forged.

[digip]

So its an OS issue directly, like a corrupted kernel, or a bad physical NIC causing the problem? What happens if you boot a live cd and do the same thing. Does it still time out?

[redxine]

Pretty sure it's the router and not a problem with software. I guess the kernel module doesn't know how to handle whatever kind of packets the router was tossing out. It causes the entire LAN to go down. No wi-fi either. I have two wireshark files here, one of just the network idling (supposedly) which contains an interesting little destination unreachable (host administratively prohibited) that is not in my /etc/hosts.deny file.

This some of these, like the first 3, are repeated.

1 0.000000 192.168.1.20 149.20.20.135 TCP 50871 > http [FIN, ACK] Seq=1 Ack=1 Win=6426 Len=0 TSV=3347857 TSER=507011864

2 0.030644 149.20.20.135 192.168.1.20 TCP http > 50871 [RST] Seq=1 Win=0 Len=0

3 0.030725 192.168.1.20 149.20.20.135 ICMP Destination unreachable (Host administratively prohibited)

.....

18 15.924668 192.168.1.1 239.255.255.250 SSDP NOTIFY * HTTP/1.1

.....

33 20.963424 200.32.222.162 192.168.1.20 TCP 10393 > 60732 [sYN] Seq=0 Win=64512 Len=0 MSS=1260

34 20.963536 192.168.1.20 200.32.222.162 TCP 60732 > 10393 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

The nmap wireshark seems fine..... no lost packets.

[decepticon_eazy_e]

Pretty sure it's the router and not a problem with software. I guess the kernel module doesn't know how to handle whatever kind of packets the router was tossing out. It causes the entire LAN to go down. No wi-fi either. I have two wireshark files here, one of just the network idling (supposedly) which contains an interesting little destination unreachable (host administratively prohibited) that is not in my /etc/hosts.deny file.

This some of these, like the first 3, are repeated.

The nmap wireshark seems fine..... no lost packets.

Destination unreachable is an ICMP code, not something generated that is actually being blocked by your host file.

It means that somewhere in the chain a router decided it didn't have a route for that network, or that network is denied for some reason. So the packet is actually going out and somewhere it gets a message back that it's denied. That IP is owned by the internet people, ARIN? That's a weird one. Maybe they're detecting the scan and sending custom packets back. Who knows!

[redxine]

That IP is owned by the internet people, ARIN? That's a weird one. Maybe they're detecting the scan and sending custom packets back. Who knows!

I wouldn't be surprised if Obama approved a secret 'mission' for the internet people to start attacking our networks and cause wide spread communications blackouts. Or they're making like Germany and enforcing computer security, only without the public knowing and not in the form of a law.

So why does ARIN just go and start rejecting packets on their network? o.O

And why would this cause my router to go down? Even better, why am I sending packets to them anyways?

These are the mysteries of the world.

[digip]

Or could be your ISP is doing deep packet inspection, sees what you are doing and their software is kicking you in the nut sack.

[haxwithaxe]

Or could be your ISP is doing deep packet inspection, sees what you are doing and their software is kicking you in the nut sack.

The cable based ISP's seem too be the worst when it come to freedom of info on the internet. I wouldn't be the least bit suprised if that's exactly what's happening.

At least Verizon(my evil ISP) has a profit based motive to their restrictions. Comcast and Cox seem to just like messing with people.