Technicolor TG582n router: The missing event logging manual
What started as curiosity has turned into something of a labour of love. Online information about the Technicolor TG582n router’s event logging capabilities is scarce, and scattered across a number of forums. I’ve used that information along with some analysis of my own to compile this - the missing event logging manual - in the hope that it might help others to expore their routers’ event logs in future.
2. Forwarding Technicolor TG582n event logs
3. Useful events from the Technicolor TG582n
a. Internet connection events
b. WiFi authentication events
c. Admin authentication events
d. Firewall events
e. Intrusion detection system (IDS) events
4. Example investigation using Technicolor TG582n events
The Technicolor TG582n is a common sight in British homes - and, if internet forums are a fair reflection of reality, homes in several other countries, too. It is, or was, the default ADSL router for a number of internet service providers (ISPs) and seems to be a common option to distribute to customers on bog standard tariffs who haven’t earned the Home Hubs and Sky Hubs of this world.
I used this router for several years (hence why I had one laying around) and as I grew more interested in cyber security I remember searching around several times for any information I could find regarding its logging capabilities and finding very little. So with a little more digging and the additional knowledge I’ve gained via experience since then, I thought I might be able to assemble something of a manual for anyone still using this router who wants to explore its event log and monitor their network activity.
With that mission in mind, and safe in the knowledge that even bricking the device would have no repercussions for my internet access now I had a new router, I set out to find how to gather logs from the Technicolor TG282n and to aggregate enough of them that I could give an overview of some of the most common events generated by the little box, which until then had been gathering dust in a cupboard.
Forwarding Technicolor TG582n event logs
While there may not be a manual for the Technicolor TG582n router’s event logging capabilities, there is a manual for its Telnet interface. That’s right - the manufacturer is forcing us to send our administrative credentials over an unencrypted protocol to configure the router, so make sure you don’t do this if there’s a chance anyone malicious is on your network. When we log in, we’re greeted with some nice ASCII art.
Beautiful. Now let’s turn our attention to turning on the event log. If you’re in a hurry and just want to grab recent events, you can use the command below to send whatever events are in the router’s cache to your analysis machine via syslog. Make sure you have something listening on port 514 to receive them.
But we’re looking for something a little longer lasting. Luckily, the Technicolor TG582n has a system for managing event log rules and a series of commands to view the rules, add new rules, remove rules, and start and stop the logging service. To set all events to be transmitted via syslog regardless of the service that generated them or their severity, enter the following commands.
The first command adds a syslog rule on the router. It gathers events from all facilities (or services) and at all severity levels (debug being the lowest) and transmits them via syslog to the destination IP address specified. The second command displays the list of syslog rules so we can make sure the rule was added correctly, and the final one enables the syslog service so events will begin to be transmitted.
Naturally, this means that once again we’ll need a service listening on port 514 on the destination system. If you’re sending logs for a quick check then Wireshark is probably enough. I was looking to gather events from a longer period of time to identify as many event types as possible, so I set up Logstash to receive the syslog and write the events to a file I could analyse later. A syslog server is another alternative.
Useful events from the Technicolor TG582n
After leaving the syslog service and Logstash running for about a week, I opened the log file in Excel and manipulated the contents into a format that would enable me to filter them down to unique event types. What follows are some of the most useful and/or interesting events I picked out from the logs.
Internet connection events
Let’s start with the basics. Most times you check your router logs, you’re likely to be investigating connectivity issues and checking to see whether you have an internet connection. These events relating to the point-to-point protocol (PPP) will hopefully provide you with an answer.
The first event is the one you’ll hope not to see. As the
link down message suggests, this event is generated when your internet connection fails and you no longer have a connection to your ISP.
The next two events are generated when you try to reconnect and relate to the challenge-handshake authentication protocol (CHAP). Your router recieves an authentication challenge from your ISP, provides your credentials, and gets an
authentication ok response if everything checks out. Then you’ll see the final
link up event when the internet connection is back up and running.
WiFi authentication events
As soon as I started scanning the logs, one event stood out as potentially useful in catching perhaps the most common of wireless network attacks: unauthorised attempts to access the WiFi network.
There’s some debate online about exactly what this event means, and people have seen it pop up in all sorts of unexpected ways (including one forum user whose stolen PlayStation 3 was apparently haunting his router and failing to connect to the network on a regular basis).
Although it sounds like it might refer to an access point, a “wireless station” in networking jargon is actually a device that can join the wireless network. In my case these events all featured the MAC address of an Apple device - and not one of my own - so that would be an obvious one to block, just to be safe.
Admin authentication events
The bread and butter of security event logging is authentication: who is logging in and out of your system and who is failing to log in using an incorrect password? This is doubly important for admin accounts, and the Technicolor TG582n’s syslog has got you covered with a few takes on these common events.
The first two events are what you would expect to see for a normal administrative session - one for when the user logs in and one for when they log out. The important thing is that Technicolor has included the username and the source IP address, which are key details if you’re planning to apply any kind of detection logic to these logs or even manually trying to investigate potential attacks.
The third event is misleading. A user “tried to” log in? Many devices would follow this up with an authentication success or failure event, but in this case it actually signifies a failed login by itself. Unfortunately, while we again get the username and source IP address, we do not get one critical detail: whether the failure was due to a bad username or an incorrect password.
Finally, we have an event that may help to track user sessions that do not end with a
LOGOUT event. When the Telnet connection is left idle for a while, the Technicolor TG582n eventually closes it, and it seems that’s when this event is created. It’s unlikely to pop up too often, but still potentially useful to know.
The firewall is in charge of allowing or denying traffic based on its source and destination and the connection type. First up, here the the events that the Technicolor TG582n generates when somebody makes changes to its firewall rules. As you can see, they’re fairly self-explanatory.
As you might suspect, these are generated when firewall rules are created, modified, and deleted respectively. One thing to watch out for with these, however, is that all three events seem to be generated in this order when a connection to the internet is established. So don’t be surprised if you see them crop up at points in the logs that you weren’t expecting them if the router was connecting to your ISP. Their effect will also require some investigation, as they don’t actually state which rules were changed.
Next, let’s look at the firewall in action. In the week the router was active, the firewall sprung into action on the following three occasions, all of which related to internet control message protocol (ICMP) traffic.
Unfortunately there’s no authority on what these actually mean. I’d expect a “replay check” to attempt to stop replay attacks, but the leading theory on the forums seems to be that this event means the firewall has prevented your router from providing a response to an ICMP ping from an attacker performing reconnaissance and attempting to discover information about your network. I have, however, also seen this occurring on outbound traffic to DNS servers from my Pi-hole, so your guess is as good as mine and any additional information anyone might be able to share would be appreciated.
Intrusion detection system (IDS) events
There’s a reason they say to start with your home network if you want to learn about cyber security. Looking through the IDS log will give you a nice insight into all the potentially nasty stuff targeting your network and give you a newfound appreciation for all the work your little Technicolor TG582n does.
The IDS appears to have detection rules for potential denial of service (DoS) attacks. In the first event, too many UDP packets were detected between the same IP addresses. This typically appears to be followed up by a UDP rate limiting event as the router attempts to protect the network against the perceived attack. What’s pretty cool is that this also appears to apply to outgoing traffic, so if your devices become infected and form part of a botnet they are prevented from spamming the attackers’ targets with packets.
The second event in my sample concerns TCP rate limiting and in my logs was applied to an IP address from Russia. An IDS applies rate limiting when it receives a large number of connection requests from a particular IP address and applies a temporary block to avoid a denial of service (DoS) condition. Note that this wouldn’t stop a distributed denial of service (DDoS) attack, which achieves the same result by sending a smaller number of packets from each of a large number of IP addresses.
Then we have various types of detected port scans - in my case detected from IP addresses belonging to organisations as varied as Akamai, Amazon, GoDaddy, and Twitch, as well as a few IP addresses that looked like Russian hackers. Not much you can do about that, but it’s interesting stuff nonetheless.
Finally, we have a TCP null port packet detection (in my logs the destination port showed up as 0). I couldn’t find too much information about this, but it’s likely to be a sign that an attacker is crafting nonsensical packets in an attempt to elicit an abnormal response from the router.
Example investigation using Technicolor TG582n events
Where does knowing all this get you? Having visibility of your router events and understanding what they mean can help you to troubleshoot network issues and identify potential cyber attacks - anything from sophisticated intruders to neighbours hijacking your broadband connection.
As an example of how the Technicolor TG582n’s event logs can come in useful, during the week I was running the router I noticed a potential problem. Like many others during the COVID-19 pandemic, I was working from home, and my Skype video calls would drop out seemingly randomly. I decided to do some digging in the new logs for any clues, and here’s what I found at around the time of one of my failed calls…
My best theory is this: The router spotted the large number of UDP datagrams being sent between my system and the Skype server and assumed this was a DoS attack. To put a stop to it, it applied rate limiting to the connection, which disrupted the call. Somewhere along the line this upset something, and that something failing took the connection down, meaning I had to wait for the broadband connection to resume before signing back into Skype, reconnecting to the call, and giving my apologies.
Unfortunately, there’s little that you could do about this particular issue. The Technicolor TG582n gives you the option of turning the IDS on or off, and there is no configuration to be done beyond that - you’re either protected or you’re not. I suppose that means I should be glad that I’ve since upgraded.
Event enumeration without proper documentation is often very hit-and-miss. I left the Technicolor TG582n router running for about a week to generate as many different events as possible, but if a certain type of event simply didn’t occur, it won’t have shown up in my analysis. If you have important and/or interesting events to add to this list, please get in touch via the links below and I’ll add them in (with credit!).