Bogus DOS attack? STB broadcasts to nowhere
gasbag1
Enthusiast - Level 2

[This is a cross-post, didn't notice 'til I was done that 'Re: MOCA Broadcast and Multicast on LAN from the MOCA network. Any way to stop it?' was marked as solved. -gsw]

Quick question, as I have a similar problem [Re: MOCA Broadcast and Multicast on LAN from the MOCA network. Any way to stop it?]. Do you have an HD PVR? I've got what amounts to a DOS attack coming from our PVR. A tech I spoke with on another matter showed me how to get to the diags screen and it turns out there are aliased ports in the box which are using the IPv4LL addresses (169.254.xxx.yyy). So my STB is sending the broadcast messages out and eating up the RAM on the gateway machine I have to protect the internal LAN.


My next step is to try to DHCP the Verizon subnet (what a pain, how to keep that safe?) and see if the little pig gets a valid address.


Just to explain my setup, I've got a dual-nic server tied to the LAN and Verizon's subnet. Wifi comes from a router on the internal LAN. DHCP runs on the internal LAN and the gateway NIC is hard-coded to a 192.168.1.0 subnet addy. Firewall rules on the gateway machine drop the annoying broadcast packets from the Verizon subnet, but still are sucking RAM.


My objection to the port blocking technique is that it still doesn't prevent the idiot STB from blasting the network with its whiny broadcasts, and there are also other ports getting hit. That's loading mercury with a pitchfork, as far as I'm concerned.


Will keep at it,

Geoff.

0 Likes
Re: Bogus DOS attack? STB broadcasts to nowhere
Anti-Phish1
Master - Level 1

@gasbag wrote:

Firewall rules on the gateway machine drop the annoying broadcast packets from the Verizon subnet, but still are sucking RAM.

My objection to the port blocking technique is that it still doesn't prevent the idiot STB from blasting the network with its whiny broadcasts, and there are also other ports getting hit. Geoff.


Huh?  If the firewall is dropping the packet, what is sucking RAM? 

And one packet every 10 seconds is hardly "blasting" your network.

0 Likes
Re: Bogus DOS attack? STB broadcasts to nowhere
gasbag1
Enthusiast - Level 2

@Anti-Phish wrote:

@gasbag wrote:

Firewall rules on the gateway machine drop the annoying broadcast packets from the Verizon subnet, but still are sucking RAM.

My objection to the port blocking technique is that it still doesn't prevent the idiot STB from blasting the network with its whiny broadcasts, and there are also other ports getting hit. Geoff.


Huh?  If the firewall is dropping the packet, what is sucking RAM? 

And one packet every 10 seconds is hardly "blasting" your network.


Never mentioned ten seconds, it's more like 2-5. The drop rule also logs it, so maybe that's it? All I know is free RAM is knocked down by 88 bytes every time the broadcast message goes by...

0 Likes
Re: Bogus DOS attack? STB broadcasts to nowhere
Anti-Phish1
Master - Level 1

@gasbag wrote:

Never mentioned ten seconds, it's more like 2-5. The drop rule also logs it, so maybe that's it? All I know is free RAM is knocked down by 88 bytes every time the broadcast message goes by...


It was prisaz that mentioned 10 seconds.  That's also what I've observed in Wireshark traces.

If you have 4 STBs, then one packet every 2.5 seconds would be expected.

You don't indicate what your "gateway machine" is.  If free RAM on that machine is dropping by 88 bytes every time a packet is dropped, then that machine has a memory leak.  Dropping a UDP packet should not cause a memory leak.  The software may be allocating 88 bytes from the heap to keep track of the packet, but that memory should be returned to the heap when the packet is dropped.

Re: Bogus DOS attack? STB broadcasts to nowhere
gasbag1
Enthusiast - Level 2

@Anti-Phish wrote:

...If you have 4 STBs, then one packet every 2.5 seconds would be expected.

You don't indicate what your "gateway machine" is.  If free RAM on that machine is dropping by 88 bytes every time a packet is dropped, then that machine has a memory leak.  Dropping a UDP packet should not cause a memory leak.  The software may be allocating 88 bytes from the heap to keep track of the packet, but that memory should be returned to the heap when the packet is dropped.


Yeah, ok, there might be a leak, but it's only the HD PVR that sends the messages, and not from the coax port addy, but from some aliased i/f inside the box. The other STBs have internal addies as well, but don't shout about it. And I don't get why the aliased i/fs don't get a legit 192.168.1.0 addie from the router. Their parents do...

As for the gateway, well, fine, it's a 200MHz PentiumPro (vroooom!) running a way-too-far-back Linux that should be rebuilt. Okay, I give... There are actually a few other reasons to update it. I just thought that when it worked so smoothly with DSL (and dial-up before that), there wouldn't be any problem. I usually don't fall for apples-to-green-apples comparisons like that, but occasionally I assume, and we know where that leads, a very dark place.

Thanks for the hand-holding, I'll post back when I've done my (practical) homework.

Regards,

Geoff.

0 Likes
Re: Bogus DOS attack? STB broadcasts to nowhere
prisaz
Legend

I also noticed my Tivo sends a beacon. So that was a whole other issue. My issue was it was filling up my log files on my Linux IP Cop router. I didn't like looking though thousands of dropped packets for the ones to be concerned with. No memory leaks on my router box, no keyboard or mouse. It runs for months with no reboot. Only perhaps an extended power failure the UPS will not handle.

My fix was to install an advanced filter rule on the Actiontec LAN to drop the packets, so my IP-Cop would not see them. Here is my network. My private network sees no Verizon STB or Tivo traffic and IP-Cop only logs incoming stuff that might make it through, but not likely. I share nothing from my computers to the STBs. I have a computer sitting on my private network connected to my flat screen.

ONT Ethernet

Actiontec WAN - MOCA Verizon STBs     

Actiontec LAN - Netgear Router - Tivo (Netgear gives Tivo access and blocks broadcast and multicast traffic)

IP Cop Router, Firewall, Proxy Server, Dan's Guardian Content Filter (OLD PC. AMD 2400 CPU, 512meg ram, 70 gig HD, multiple network cards.)

Private LAN - My Computer hardware.

Wireless Access Point- No SSID Broadcast, WPA encryption and MAC address filtering.

Rather elaborate, but I had hardware laying around.

0 Likes
Re: Bogus DOS attack? STB broadcasts to nowhere
gasbag1
Enthusiast - Level 2

@prisaz wrote:

I also noticed my Tivo sends a beacon...

My fix was to install an advanced filter rule on the Actiontec LAN to drop the packets...

ONT Ethernet

Actiontec WAN - MOCA Verizon STBs     

Actiontec LAN - Netgear Router - Tivo (Netgear gives Tivo access and blocks broadcast and multicast traffic)

IP Cop Router, Firewall, Proxy Server, Dan's Guardian Content Filter (OLD PC. AMD 2400 CPU, 512meg ram, 70 gig HD, multiple network cards.)

Private LAN - My Computer hardware.

Wireless Access Point- No SSID Broadcast, WPA encryption and MAC address filtering.

Rather elaborate, but I had hardware laying around.


On the beacon, yeah, now the STB is sending it's mewlings to the 'all 1's' address from another IP(??!!) It seems (by way of the diags screen) to _want_ to be a real connection, I just don't know why the ActionTEC's DHCP won't respond to it. And, I thought, if the interface _is_ needed for something, plus to keep more control over what's inside the house, why not add a subnet to my internal LAN DHCP and DMZ the whole of the '192.168.1.x' space. But, you're right, the less my LAN knows about Verizon's ring the better.

Am currently dealing with a cranky Win7 laptop, which has been giving me BSOD for two days. This follows an in-Home Agent install coupled with some Windows updates. For the love of Pete, make it stop! M$, in their infinite wisdom, has installed a VPN to make sure they can bore a hole straight into my brain, and I believe iHA does the same thing, as 'ipconfig' produces several tunneling i/fs. Had to undo the TCP/IP setup to remove my home LAN DNS suffix, as the Windoze tunnel got all confused. Also borked my Linux laptop with something so dumb I won't repeat it here. But I did manage to install Slack64 on the Win7 laptop, so I'll have that to play with, and restore my mail to, while I repair the old laptop.

Well, _that_ was a bit far afield, thanks for the indulgence. And this arrived at the perfect time, enjoy.

I hear you on the elaborate setup, as you can tell, and I'm thinking of expanding the GW machine to include Dan's and a proxy as well.

Again, thanks for walking me through it, I'll start hacking the ActionTEC soon.

Regards,

Geoff.