george on 29 Mar 2018 16:08:04 -0700


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[PLUG] Verizon router's security log fills up too frequently 

Today I discovered rather belatedly that there is far too much activity
happening in the Security Log of my ActionTec Wireless Router, courtesy
Verizon FIOS. I've had it for a number of years, and in the past I've
never seen the activity that surfaced today when I checked it for no good 
reason.

The Log File had filled up and stopped recording all the craziness that
has been happening since the Russians started messing around with our 'Net. 

Start rant:
Here's what's been eating up several hours a day for the past few months: 
http://www.pinthetaleonthedonkey.com. The Russians are working toward a
granddaddy DOS attack. One set of brute force hits on WordPress weaknesses escalated from 22 in a row in December to 44 in January to 89 in February; I'm expecting much worse in the March raw access log ... They are perfecting the timing of HEAD / HTTP requests to get to MyDomain.com at the same second 
on the clock, with a view towards overwhelming some unsuspecting Windows
users when the Czar hacker activates Port 3389 on the participating servers. 

Back to the router:
So I saved what there was and restarted the log ... only to be greeted with 
another filled-up log in a couple of hours ... and again ... and again,
just today. Something has got to be changed.
And it's not the Russians who are leaving their tracks all over my router; OK, maybe a few CloudFlare hits, a couple from Germany, one from Israel,one 
from France, one Chinese, but the rest are from Google, Amazon, Akamai,
Adobe and lesser known US folks.
But the most hits are nuisance procedural hits purportedly having something 
to do with the non-existent domain, 224.0.0.22. A Google search reveals
that it's the result of some programmers not coordinating their efforts
between competing applications. That glitch accounts for about 90% of the 
entries in the Security Log, and they need to get dropped if we can't
make them go away in a less crude fashion.

The ActionTect router gets nice reviews for wireless FIOS, but there is
nowhere near enough storage for the Security Log. I can't just trot down
to MicroCenter and get a better one ...

Here's a snippet for a good 224.0.0.22 example:
Mar 29 16:19:33 2018 Inbound Traffic Blocked - Spoofing protection IGMP 173.49.200.99->224.0.0.22 on eth1[repeated 31 times, last time on Mar 29 16:20:03 2018] Mar 29 16:07:46 2018 Firewall Info Rate Limit 1 messages of type [12] Spoofing protection suppressed in 1 second(s) Mar 29 16:07:45 2018 Inbound Traffic Blocked - Spoofing protection IGMP 173.49.200.99->224.0.0.22 on eth1 Mar 29 16:07:45 2018 Firewall Info Rate Limit 2 messages of type [12] Spoofing protection suppressed in 1 second(s) Mar 29 16:07:13 2018 Inbound Traffic Blocked - Spoofing protection IGMP 173.49.200.99->224.0.0.22 on eth1[repeated 31 times, last time on Mar 29 16:07:44 2018] Mar 29 15:37:14 2018 Firewall Info Rate Limit 1 messages of type [12] Spoofing protection suppressed in 1 second(s) Mar 29 15:37:13 2018 Inbound Traffic Blocked - Spoofing protection IGMP 173.49.200.99->224.0.0.22 on eth1 Mar 29 15:37:13 2018 Firewall Info Rate Limit 1 messages of type [12] Spoofing protection suppressed in 1 second(s) Mar 29 15:37:11 2018 Inbound Traffic Blocked - Spoofing protection IGMP 173.49.200.99->224.0.0.22 on eth1 Mar 29 15:37:11 2018 Firewall Info Rate Limit 1 messages of type [12] Spoofing protection suppressed in 1 second(s) 

Here's a snippet of some different activity:
Mar 29 17:53:10 2018 Inbound Traffic Blocked - Packet invalid in connection TCP 65.222.200.75:80->173.49.200.99:64642 on eth1 Mar 29 17:53:06 2018 Outbound Traffic Blocked - First packet is Invalid TCP 192.168.1.3:64636->23.52.143.66:443 on eth1 Mar 29 17:52:57 2018 Outbound Traffic Blocked - First packet is Invalid TCP 192.168.1.3:64635->23.52.143.66:443 on eth1 Mar 29 17:52:51 2018 Inbound Traffic Blocked - Packet invalid in connection TCP 23.52.143.66:443->173.49.200.99:64635 on eth1 Mar 29 17:52:01 2018 Outbound Traffic Blocked - First packet is Invalid TCP 192.168.1.3:64579->104.25.226.100:443 on eth1 Mar 29 17:45:52 2018 Inbound Traffic Blocked - Packet invalid in connection TCP 13.33.74.8:80->173.49.200.99:64560 on eth1[repeated 2 times, last time on Mar 29 17:45:54 2018] Mar 29 17:42:39 2018 Firewall Info Rate Limit 1 messages of type [65] First packet is Invalid suppressed in 1 second(s) Mar 29 17:42:38 2018 Outbound Traffic Blocked - First packet is Invalid TCP 192.168.1.3:64492->104.100.132.85:443 on eth1 

The LAN address in the second snippet above is the Missus' laptop.

Here's a short snippet with a CloudFlare connection:
Mar 29 16:56:35 2018 Inbound Traffic Blocked - Packet invalid in connection TCP 104.16.50.134:443->173.49.200.99:64263 on eth1 Mar 29 16:56:14 2018 Outbound Traffic Blocked - First packet is Invalid TCP 192.168.1.3:64254->104.16.51.134:443 on eth1
where 104.16.50.134 and 104.16.51.134 is a typical CloudFlare domain IPv4 
address pairing; but I didn't know the domain name until Google revealed
through Hurricane Electric that the pair represents two of the five IPv4
addresses assigned to peapod.com by the CloudFlare service ... and Mrs. L just made an order through PeaPod for delivery of groceries ... so that's 
clearly an innocent Firewall Security Log occurrence.

Is the Actiontec router just being paranoid ?

Thanks,
George Langford
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug