MattCASmith

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.

Contents

1. Background
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
5. Contribute

Background

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.

syslog msgbuf send dest=<destination_ip>

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.

syslog ruleadd fac=all sev=debug dest=<destination_ip>
syslog list
syslog config activate=enabled

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.

PPP link down (Internet) [<source_ip>]
PPP CHAP receive challenge (rhost = <destination_hostname>)
PPP CHAP chap receive success : authentication ok
PPP link up (Internet) [<source_ip>]

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.

LOGIN wireless station [<mac_address>] can't get authorized

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.

LOGIN User <username> logged in on TELNET (<source_ip>)
LOGOUT User <username> logged out on TELNET (<source_ip>)
LOGIN User <username> tried to log in on TELNET (<source_ip>)
SESSION TIMEOUT Timeout! (after 600 sec)

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.

Firewall events

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.

FIREWALL event (x of x): created rules
FIREWALL event (x of x): modified rules
FIREWALL event (x of x): deleted rules

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.

FIREWALL replay check (<x> of <x>): Protocol: ICMP  Src ip: <source_ip> Dst ip: <destination_ip> Type: Destination Unreachable Code: Port Unreacheable
FIREWALL icmp check (<x> of <x>): Protocol: ICMP  Src ip: <source_ip> Dst ip: <destination_ip> Type: Destination Unreachable Code: Port Unreacheable
FIREWALL icmp check (<x> of <x>): Protocol: ICMP  Src ip: <source_ip> Dst ip: <destination_ip> Type: Echo Reply Code: 0

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.

IDS dos parser : idp flood (1 of 1) : <source_ip> <destination_ip> 0801 UDP <source_port>-><destination_port>
IDS rate parser : tcp rate limiting (1 of 1) : <source_ip>   <destination_ip>   0040 TCP <source_port>-><destination_port> [S.....] seq 100 win 1024
IDS scan parser : tcp port scan: <destination_ip> scanned at least 10 ports at <destination_ip>.  (1 of 1) : <source_ip>   <destination_ip>   0040 TCP <source_port>-><destination_port> [...R..] seq 11694198 win 0
IDS scan parser : udp port scan: <source_ip> scanned at least 20 ports at <destination_ip>.  (1 of 1) : <source_ip>  <destination_ip>   0441 UDP <source_port>-><destination_port>
IDS scan parser : tcp syn scan: <source_ip> scanned at least 20 ports at <destination_ip>.  (1 of 1) : <source_ip>   <destination_ip>   0040 TCP <source_port>-><destination_port> [S.....] seq 97417629 win 1024
IDS proto parser : tcp null port (1 of 1) : <source_ip> <destination_ip>   0040 TCP <source_port>-><destination_port> [S.....] seq 2505992964 win 1024

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…

IDS dos parser : udp flood (1 of 1): <my_ip> <company_server_ip> 0801 UDP <source_port>-><destination_port>
IDS rate parser : udp rate limiting (1 of 1): <my_ip> <company_server_ip> 1072 UDP <source_port>-><destination_port>
PPP link down (Internet) [<my_ip>]
PPP CHAP Receive challenge (rhost = <host>)
PPP CHAP Chap receive success : authentication ok
PPP link up (Internet) [<my_ip>]

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.

Contribute

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!).