
Hi Folks I'm just wondering if anyone has any feedback regarding this situation. I maintain a multi homed Linux router in the Seychelles Islands for the Seychelles government and the CTO of one of the ISP's wants me to use an IP of 217.161.116.143 with a netmask of 255.255.255.255 and a default gateway of 217.161.116.8. To explain it further they are running a fibre optic link to my linux router and at the other end of it they've got a cisco 2500 with an IP of 217.161.116.8. What I get is ethernet and they want me to use the IP 217.161.116.143 with a netmask of 255.255.255.255 on my linux router. I do not want to run IP unnumbered and anyway I cannot think of how anything but a CISCO can talk IP unnumbered to another CISCO. Everything I know and everything I ever learned says this is mission impossible. I am at a loss of words on what to say to this. Am I missing something here perhaps ? Can anyone think of anything to say to this. This ISP is called Atlas and their URL is http://www.seychelles.net They also happen to be the operators of the .sc ccTLD I would greatly appreciate any feedback from anyone as to what I could possibly say to these people. Then again maybe I missed something and maybe I am wrong ? Cheers Tikiri

On 21 Oct 2003, at 11:04, Tikiri Wicks wrote:
I'm just wondering if anyone has any feedback regarding this situation. I maintain a multi homed Linux router in the Seychelles Islands for the Seychelles government and the CTO of one of the ISP's wants me to use an IP of 217.161.116.143 with a netmask of 255.255.255.255 and a default gateway of 217.161.116.8.
If it was me, I'd want to see a diagram of exactly what was connected where. If your box is connected to the same broadcast domain as his box, you can probably ARP for your default gateway and find it without having an interface address in the same subnet. On a cisco you can do this with an interface route ("ip route 217.161.116.8 255.255.255.255 eth0"); you'll see this exposed as a connected route with appropriate distance. But it's all pretty ugly. Joe

On Tue, 21 Oct 2003 at 11:43:29 -0500, Joe Abley wrote:
On 21 Oct 2003, at 11:04, Tikiri Wicks wrote:
??? I'm just wondering if anyone has any feedback regarding this situation.
<snip>
If your box is connected to the same broadcast domain as his box, you can probably ARP for your default gateway and find it without having an interface address in the same subnet. On a cisco you can do this with an interface route ("ip route 217.161.116.8 255.255.255.255 eth0"); you'll see this exposed as a connected route with appropriate distance.
For linux (with correct kernel +options / iproute tools) use "ip ro add 217.161.116.8/32 dev eth0" from your preferred shell for the same effect. Your box will then try arp solicitation for this address via eth0. Or if you prefer a more Cisco like implementation then I'd suggest the Zebra routing daemon[s] and Joe's command above. Matt.

Thanks Joe / Matt I've built the kernel with with iproute 2 and iptables support So can I assume ip address add 217.161.116.143/32 dev eth0 label eth0:atlas143 ip address add 217.161.116.144/32 dev eth2 label eth2:atlas144 ip address add 217.161.116.145/32 dev eth2 label eth2:atlas145 ip route add 217.161.116.8/32 dev eth0 and either: 1) ip route add default scope global nexthop via 217.161.116.8 dev eth0 weight 1 nexthop via 64.110.101.65 dev eth3 weight 1 or 2) ip route add default scope global via 217.161.116.8 dev eth0 along with the following NAT for each private network behind the router iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth0 -j SNAT --to 217.161.116.143 iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth3 -j SNAT --to 64.110.101.70 plus iptables DNAT rules for whatever on the 144, 145 and upwards IP's p.s. Joe in about a month or two I will have a router / firewall built using dual opteron cpu's for a total of 33 ethernet ports at 100 mbps (tulip chipset) plus 2 channel bonded gigabit ethernet ports as a 2 gbps backplane to other devices. Once that puppy is built would you be interested in looking at it. Just waiting for them to pay for the hardware. It's along the lines of your previous advice on multi port routers but on a slightly larger scale. Similar configuration on a smaller scale with a P4 - 2GHz chip has a thoughput of approx 540 mbps at 92% CPU. I'm hoping that the dual opteron with it's hypertransport bus will be able to handle the potential maximum of around 5 gbps. Only sad bit is that the unit is a full 9U. If CPU doesn't get maxed out it will also double as a RAID5 NAS for archiving of large files. If your interested in looking at it once it's built please please let me know. Cheers Tikiri ----- Original Message ----- From: "Matt Sullivan" <matt(a)sullivan.gen.nz> To: "Joe Abley" <jabley(a)isc.org> Cc: "Tikiri Wicks" <tcwicks(a)maxnet.co.nz>; <nznog(a)list.waikato.ac.nz> Sent: Wednesday, October 22, 2003 10:48 AM Subject: Re: [nznog] What can I say to this
On Tue, 21 Oct 2003 at 11:43:29 -0500, Joe Abley wrote:
On 21 Oct 2003, at 11:04, Tikiri Wicks wrote:
??? I'm just wondering if anyone has any feedback regarding this situation.
<snip>
If your box is connected to the same broadcast domain as his box, you can probably ARP for your default gateway and find it without having an interface address in the same subnet. On a cisco you can do this with an interface route ("ip route 217.161.116.8 255.255.255.255 eth0"); you'll see this exposed as a connected route with appropriate distance.
For linux (with correct kernel +options / iproute tools) use "ip ro add 217.161.116.8/32 dev eth0" from your preferred shell for the same effect. Your box will then try arp solicitation for this address via eth0. Or if you prefer a more Cisco like implementation then I'd suggest the Zebra routing daemon[s] and Joe's command above.
Matt.

Hi Just wondering if anyone can shed some light on this. 13 PC's in a network of about 300 PC's keep incrementally pinging everything in their netmask For example PC with IP 172.20.10.2 will start pinging 172.20.10.1 and ping all the way upto 172.20.10.255. Then it starts over These are all windows 2000 machines and each one is generating about a hundred icmp packets per second incrementally counting through every destination IP in their netmask. If I change one of the machines netmask to /16 then it starts pinging everything in that entire class b starting at 1.1 and incrementally counting upto the top. These are all normal windows 2000 PC's Does anyone have an idea on this ??? Cheers Tikiri

Thanks for the feedback so far but it's not viruses. Virus checks turned up nothing and it's definitely not the blaster virusas all the machines were patched for that when it came out. I've used both Norton as well as F-Secure to check the PC's but nothing turns up There is nothing special about these PC's either. Standard build of windows 2000 and most probably installed from the same disk set. Master Browser discovery ??? but that I thought was netbios Still hunting :-( ----- Original Message ----- From: "Tikiri Wicks" <tcwicks(a)maxnet.co.nz> To: <nznog(a)list.waikato.ac.nz> Sent: Wednesday, October 22, 2003 10:47 PM Subject: [nznog] Windows 2000 PC's auto generating icmp packet floods
Hi
Just wondering if anyone can shed some light on this. 13 PC's in a network of about 300 PC's keep incrementally pinging everything in their netmask
For example PC with IP 172.20.10.2 will start pinging 172.20.10.1 and ping all the way upto 172.20.10.255. Then it starts over These are all windows 2000 machines and each one is generating about a hundred icmp packets per second incrementally counting through every destination IP in their netmask. If I change one of the machines netmask to /16 then it starts pinging everything in that entire class b starting at 1.1 and incrementally counting upto the top. These are all normal windows 2000 PC's
Does anyone have an idea on this ???
Cheers
Tikiri
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

Hi Tikiri, Are you able to dump a packet. Most worms etc. have a identifing stream. i.e. Nachi had hex 'a'. Cheers Steve. ----- Original Message ----- From: "Tikiri Wicks" <tcwicks(a)maxnet.co.nz> To: <nznog(a)list.waikato.ac.nz> Sent: Wednesday, October 22, 2003 11:15 PM Subject: [nznog] Not a virus - Windows 2000 PC's auto generating icmp packetfloods
Thanks for the feedback so far but it's not viruses.
Virus checks turned up nothing and it's definitely not the blaster virusas all the machines were patched for that when it came out. I've used both Norton as well as F-Secure to check the PC's but nothing turns up There is nothing special about these PC's either. Standard build of windows 2000 and most probably installed from the same disk set. Master Browser discovery ??? but that I thought was netbios
Still hunting :-(
----- Original Message ----- From: "Tikiri Wicks" <tcwicks(a)maxnet.co.nz> To: <nznog(a)list.waikato.ac.nz> Sent: Wednesday, October 22, 2003 10:47 PM Subject: [nznog] Windows 2000 PC's auto generating icmp packet floods
Hi
Just wondering if anyone can shed some light on this. 13 PC's in a network of about 300 PC's keep incrementally pinging everything in their netmask
For example PC with IP 172.20.10.2 will start pinging 172.20.10.1 and ping all the way upto 172.20.10.255. Then it starts over These are all windows 2000 machines and each one is generating about a hundred icmp packets per second incrementally counting through every destination IP in their netmask. If I change one of the machines netmask to /16 then it starts pinging everything in that entire class b starting at 1.1 and incrementally counting upto the top. These are all normal windows 2000 PC's
Does anyone have an idea on this ???
Cheers
Tikiri
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

Hi Tikiri,
Are you able to dump a packet. Most worms etc. have a identifing stream. i.e. Nachi had hex 'a'.
Cheers Steve.
----- Original Message ----- From: "Tikiri Wicks" <tcwicks(a)maxnet.co.nz> To: <nznog(a)list.waikato.ac.nz> Sent: Wednesday, October 22, 2003 11:15 PM Subject: [nznog] Not a virus - Windows 2000 PC's auto generating icmp packetfloods
Thanks for the feedback so far but it's not viruses.
Virus checks turned up nothing and it's definitely not the blaster virusas all the machines were patched for that when it came out. I've used both Norton as well as F-Secure to check the PC's but nothing turns up There is nothing special about these PC's either. Standard build of windows 2000 and most probably installed from the same disk set. Master Browser discovery ??? but that I thought was netbios
Still hunting :-(
----- Original Message ----- From: "Tikiri Wicks" <tcwicks(a)maxnet.co.nz> To: <nznog(a)list.waikato.ac.nz> Sent: Wednesday, October 22, 2003 10:47 PM Subject: [nznog] Windows 2000 PC's auto generating icmp packet floods
Hi
Just wondering if anyone can shed some light on this. 13 PC's in a network of about 300 PC's keep incrementally pinging everything in
My apologies if this is really off topic for this list. I'm just deperate for help. Right now I can contain it by blocking ICMP at the central routers. However we are now getting bombed from the Internet side with icmp packets very simillar to what we are seeing on the internal network. ICMP packets per second recieved from the Internet side looks like it's growing. I dumped the contents of a number of the packets and it is all random binary data. Contents of one packet is attached. used tcpdump -i eth1 -w testcap -c 1 icmp This network is a WAN encompassing almost all the PC's at the government of Seychelles. There are two distict behaviours. some of the machines are incrementally pinging counting through IP's while others are just pinging at random Incremental counting example Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.58 172.21.219.1 echo req Wed Oct 22 10:06:48 2003 ICMP eth1 92 bytes 172.20.13.58 172.21.219.10 echo req Wed Oct 22 10:06:48 2003 ICMP eth1 92 bytes 172.20.13.58 172.21.219.100 echo req Wed Oct 22 10:06:48 2003 ICMP eth1 92 bytes 172.20.13.58 172.21.219.101 echo req Wed Oct 22 10:06:48 2003 ICMP eth1 92 bytes 172.20.13.58 172.21.219.102 echo req Wed Oct 22 10:06:48 2003 ICMP eth1 92 bytes 172.20.13.58 172.21.219.103 echo req Wed Oct 22 10:06:48 2003 ICMP eth1 92 bytes 172.20.13.58 172.21.219.104 echo req Wed Oct 22 10:06:49 2003 ICMP eth1 92 bytes 172.20.13.58 172.21.219.105 echo req Wed Oct 22 10:06:49 2003 ICMP eth1 92 bytes 172.20.13.58 172.21.219.106 echo req Wed Oct 22 10:06:49 2003 ICMP eth1 92 bytes 172.20.13.58 172.21.219.107 echo req Wed Oct 22 10:06:49 2003 ICMP eth1 92 bytes 172.20.13.58 172.21.219.108 echo req Wed Oct 22 10:06:49 2003 ICMP eth1 92 bytes 172.20.13.58 172.21.219.109 echo req This is a list of packets generated to random IP's by one of the buggered machines within one second. Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 134.201.148.92 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 134.245.149.187 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 134.6.35.67 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 134.80.86.18 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 135.106.165.163 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 135.121.107.85 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 135.156.232.33 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 135.171.152.120 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 135.21.78.74 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 135.232.78.121 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 135.24.134.106 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 135.249.194.105 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 135.6.250.118 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 135.90.48.142 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 136.193.190.190 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 136.2.207.62 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 136.205.182.175 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 136.219.249.129 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 136.224.49.245 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 136.236.246.88 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 136.249.217.60 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 136.43.157.84 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 137.1.24.83 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 137.116.252.40 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 137.12.26.164 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 137.203.34.244 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 138.86.164.87 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 138.98.156.15 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 138.99.237.131 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 139.114.18.154 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 139.115.153.166 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 139.140.147.214 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 139.224.2.109 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 140.16.1.95 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 140.218.126.39 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 140.22.209.12 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 140.243.246.117 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 140.68.153.239 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 140.72.181.149 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 140.91.46.230 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 141.183.123.247 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 141.225.101.23 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 141.27.59.2 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 141.69.172.112 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 142.17.7.249 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 142.52.236.154 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 143.105.255.186 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 143.11.183.189 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 143.150.2.179 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 143.30.245.9 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 143.32.107.116 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 143.37.124.54 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 144.160.111.25 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 144.180.159.246 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 144.207.201.216 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 144.50.13.114 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 144.70.56.193 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 145.106.19.158 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 145.124.87.240 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 145.157.43.22 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 145.21.185.29 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 145.236.203.9 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 145.41.210.106 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 145.68.213.68 echo req ----- Original Message ----- From: "Steven Schmidt" <sschmidt(a)compass.net.nz> To: <nznog(a)list.waikato.ac.nz> Sent: Thursday, October 23, 2003 12:24 PM Subject: Re: [nznog] Not a virus - Windows 2000 PC's auto generating icmppacketfloods their
netmask
For example PC with IP 172.20.10.2 will start pinging 172.20.10.1 and ping all the way upto 172.20.10.255. Then it starts over These are all windows 2000 machines and each one is generating about a hundred icmp packets per second incrementally counting through every destination IP in their netmask. If I change one of the machines netmask to /16 then it starts pinging everything in that entire class b starting at 1.1 and incrementally counting upto the top. These are all normal windows 2000 PC's
Does anyone have an idea on this ???
Cheers
Tikiri
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

Thanks everyone for your help I think it was some wiered strain of Blaster, Naichi or something. In either case all the affected machines would stop pinging if all instances of internet explorer, MSN messenger and outlook express were killed. All affected machines hapenned to have MSN messenger version 5.0. MSN messenger processes could not be killed as they were in use by something unknown other than MSN messenger. But after uninstalling MSN messenger as long as internet explorer was not launched the machines would behave. We couldn't get to the bottom of it so we wiped the affected machines and reinstalled them. Also over 3 days it did not spread to any other machine on the network besides the 13 infected ones. Finally once the machines were reinstalled the flood of icmp packets from the Internet side stopped as well. Maybe it was a new virus written by someone on the inside of the network. Maybe some kind of Internet Explorer BHO ? I got no clue but I'm glad it's over. Once again thanks to everyone for their invaluable help. Cheers Tikiri ----- Original Message ----- From: "Tikiri Wicks" <tcwicks(a)maxnet.co.nz> To: "Steven Schmidt" <sschmidt(a)compass.net.nz>; <nznog(a)list.waikato.ac.nz> Sent: Thursday, October 23, 2003 1:54 PM Subject: Re: [nznog] Not a virus - Windows 2000 PC's auto generatingicmppacketfloods
My apologies if this is really off topic for this list. I'm just deperate for help.
Right now I can contain it by blocking ICMP at the central routers. However we are now getting bombed from the Internet side with icmp packets very simillar to what we are seeing on the internal network. ICMP packets per second recieved from the Internet side looks like it's growing.
I dumped the contents of a number of the packets and it is all random binary data. Contents of one packet is attached. used tcpdump -i eth1 -w testcap -c 1 icmp
This network is a WAN encompassing almost all the PC's at the government of Seychelles.
There are two distict behaviours. some of the machines are incrementally pinging counting through IP's while others are just pinging at random
Incremental counting example
Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.58 172.21.219.1 echo req Wed Oct 22 10:06:48 2003 ICMP eth1 92 bytes 172.20.13.58 172.21.219.10 echo req Wed Oct 22 10:06:48 2003 ICMP eth1 92 bytes 172.20.13.58 172.21.219.100 echo req Wed Oct 22 10:06:48 2003 ICMP eth1 92 bytes 172.20.13.58 172.21.219.101 echo req Wed Oct 22 10:06:48 2003 ICMP eth1 92 bytes 172.20.13.58 172.21.219.102 echo req Wed Oct 22 10:06:48 2003 ICMP eth1 92 bytes 172.20.13.58 172.21.219.103 echo req Wed Oct 22 10:06:48 2003 ICMP eth1 92 bytes 172.20.13.58 172.21.219.104 echo req Wed Oct 22 10:06:49 2003 ICMP eth1 92 bytes 172.20.13.58 172.21.219.105 echo req Wed Oct 22 10:06:49 2003 ICMP eth1 92 bytes 172.20.13.58 172.21.219.106 echo req Wed Oct 22 10:06:49 2003 ICMP eth1 92 bytes 172.20.13.58 172.21.219.107 echo req Wed Oct 22 10:06:49 2003 ICMP eth1 92 bytes 172.20.13.58 172.21.219.108 echo req Wed Oct 22 10:06:49 2003 ICMP eth1 92 bytes 172.20.13.58 172.21.219.109 echo req
This is a list of packets generated to random IP's by one of the buggered machines within one second.
Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 134.201.148.92 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 134.245.149.187 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 134.6.35.67 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 134.80.86.18 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 135.106.165.163 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 135.121.107.85 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 135.156.232.33 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 135.171.152.120 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 135.21.78.74 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 135.232.78.121 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 135.24.134.106 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 135.249.194.105 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 135.6.250.118 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 135.90.48.142 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 136.193.190.190 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 136.2.207.62 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 136.205.182.175 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 136.219.249.129 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 136.224.49.245 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 136.236.246.88 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 136.249.217.60 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 136.43.157.84 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 137.1.24.83 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 137.116.252.40 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 137.12.26.164 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 137.203.34.244 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 138.86.164.87 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 138.98.156.15 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 138.99.237.131 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 139.114.18.154 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 139.115.153.166 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 139.140.147.214 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 139.224.2.109 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 140.16.1.95 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 140.218.126.39 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 140.22.209.12 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 140.243.246.117 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 140.68.153.239 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 140.72.181.149 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 140.91.46.230 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 141.183.123.247 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 141.225.101.23 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 141.27.59.2 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 141.69.172.112 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 142.17.7.249 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 142.52.236.154 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 143.105.255.186 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 143.11.183.189 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 143.150.2.179 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 143.30.245.9 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 143.32.107.116 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 143.37.124.54 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 144.160.111.25 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 144.180.159.246 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 144.207.201.216 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 144.50.13.114 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 144.70.56.193 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 145.106.19.158 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 145.124.87.240 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 145.157.43.22 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 145.21.185.29 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 145.236.203.9 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 145.41.210.106 echo req Wed Oct 22 10:06:47 2003 ICMP eth1 92 bytes 172.20.13.111 145.68.213.68 echo req
----- Original Message ----- From: "Steven Schmidt" <sschmidt(a)compass.net.nz> To: <nznog(a)list.waikato.ac.nz> Sent: Thursday, October 23, 2003 12:24 PM Subject: Re: [nznog] Not a virus - Windows 2000 PC's auto generating icmppacketfloods
Hi Tikiri,
Are you able to dump a packet. Most worms etc. have a identifing stream. i.e. Nachi had hex 'a'.
Cheers Steve.
----- Original Message ----- From: "Tikiri Wicks" <tcwicks(a)maxnet.co.nz> To: <nznog(a)list.waikato.ac.nz> Sent: Wednesday, October 22, 2003 11:15 PM Subject: [nznog] Not a virus - Windows 2000 PC's auto generating icmp packetfloods
Thanks for the feedback so far but it's not viruses.
Virus checks turned up nothing and it's definitely not the blaster virusas all the machines were patched for that when it came out. I've used both Norton as well as F-Secure to check the PC's but nothing turns up There is nothing special about these PC's either. Standard build of windows 2000 and most probably installed from the same disk set. Master Browser discovery ??? but that I thought was netbios
Still hunting :-(
----- Original Message ----- From: "Tikiri Wicks" <tcwicks(a)maxnet.co.nz> To: <nznog(a)list.waikato.ac.nz> Sent: Wednesday, October 22, 2003 10:47 PM Subject: [nznog] Windows 2000 PC's auto generating icmp packet floods
Hi
Just wondering if anyone can shed some light on this. 13 PC's in a network of about 300 PC's keep incrementally pinging everything in their netmask
For example PC with IP 172.20.10.2 will start pinging 172.20.10.1 and ping all the way upto 172.20.10.255. Then it starts over These are all windows 2000 machines and each one is generating about a hundred icmp packets per second incrementally counting through every destination IP in their netmask. If I change one of the machines netmask to /16 then it starts pinging everything in that entire class b starting at 1.1 and incrementally counting upto the top. These are all normal windows 2000 PC's
Does anyone have an idea on this ???
Cheers
Tikiri
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
---------------------------------------------------------------------------- ----
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

It sounds to me like the Nachi/Welchia virus, it could be a new variant. Have you tried doing a "netstat -ano" on a infected machine and seeing if there are any port open that should not be, like 4444 or 707. And then look for the PID in task manager. You could also use something like Tcpview. http://www.sysinternals.com/ntw2k/source/tcpview.shtml jfp. ------------------------------------------------------------------------ Jean-Francois Pirus <jfp(a)clearfield.com> Clearfield Software Ltd Phone (+64-9) 358 2081 4th Floor 8-10 Whitaker Place Fax (+64-9) 358 2083 P O Box 2348 Auckland, New Zealand ------------------------------------------------------------------------
participants (5)
-
jfp
-
Joe Abley
-
Matt Sullivan
-
Steven Schmidt
-
Tikiri Wicks