lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
From: marc at (Marc Chabot (.net))
Subject: Linksys MULTICAST sieve (was WinME firewalling)

Salut Paul,

Monday, November 10, 2003, 10:46:29 AM, a ?crit:
SPL> In case you're not aware of it, those little routers include a
SPL> firewall, IDS (which can be configured to email alerts to him
SPL> instead of granny), DHCP, NAT and MAC ACL restrictions. The boxes
SPL> behind those are on private IP space and there are no open
SPL> incoming ports. You can lock down a box pretty good behind one of
SPL> them.

An end user on a cable ISP using a linksys befsr41 v3 with firmware
1.04.8 was (and still is) being hit with a gazillion multicast UDP
packets on port 15205.  Turns out it's a new rogue ms server flooding
the pipe.

Setting the Filter Port Range to block all UDP from port 137 to 65535
didn't stop anything, nor playing with Filter Multicast:Enabled
Disabled or anything else.

All the packets get through the NAT box and hit all the NICs.  This
NAT box was (is) monitored by kiwi syslog, and none of these packets
make a single trace in the logs, even when looking at the internal
simple but free Incoming Log Table (so it's not a syslog configuration
phoque up).  So long for email alerts!

No matter what you do with the NAT box, all those packets are
broadcated inside the private IP space.

I might be stupid, but I beleive this is a bug, somehow.  :-D

It's a bit like port 113 being closed (not stealth) when scanned to
avoid slowing some software monitoring that port, looks like a bug,
but it's a feature.   Apparently.

Linksys have a support php chat thing, but it was too busy, so an
"email" was used instead (throught the same php thing), with all details
about this bug/feature.  No answer from them, yet.

It might be interesting to see when a script kiddie began modifying
slammer or the next worm using udp to target the multicast just to
get throught as many cheap NAT boxes as he can.  It will be fun!  :-D

I didn't spent more than two minutes trying to know if those packets
are voice over ip or porn, but if any curious mind care to do a
IGMP join-group:

23:15:04.927138 IP > udp 1452
23:15:04.959543 IP > udp 1452
23:15:05.005395 IP > udp 1452
23:15:05.067469 IP > udp 1452
23:15:05.119350 IP > udp 1452

the rogue flooder is:

Starting nmap 3.48 ( ) at 2003-11-06 23:07 Eastern Standard Time
Host ( appears to be up ... good.
Initiating SYN Stealth Scan against ( at 23:07
Adding open port 1755/tcp
Adding open port 554/tcp
Adding open port 80/tcp
The SYN Stealth Scan took 67 seconds to scan 1657 ports.
Initiating service scan against 3 services on 1 host at 23:08
The service scan took 41 seconds to scan 3 services on 1 host.
Warning:  OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port
For OSScan assuming that port 80 is open and port 39187 is closed and neither are firewalled
Interesting ports on (
(The 1654 ports scanned but not shown below are in state: filtered)
80/tcp   open  http    Microsoft IIS webserver 6.0
554/tcp  open  rtsp    Microsoft Windows Media Server
1755/tcp open  wms?
Device type: general purpose
Running: Microsoft Windows 2003/.NET|NT/2K/XP
OS details: Microsoft Windows Server 2003 Enterprise Edition, Microsoft Windows 2000 SP3
TCP Sequence Prediction: Class=truly random
                         Difficulty=9999999 (Good luck!)
IPID Sequence Generation: Busy server or unknown class

Nmap run completed -- 1 IP address (1 host up) scanned in 112.150 seconds

Yours Digitally,
 CanonBall                            mailto:

We don't just delete spam, we delete spammers.

Powered by blists - more mailing lists