I found a smart lightbulb using a common IRC port 6668 in Nmap, should I be worried?
I was going through my connected client list trying to add some alias names to my devices to help keep track of what is connected to my network.
I noticed one device that I didn't have a name for, and had trouble trying to track down what it was.
Checked the MAC address to try and find the vendor and got some basic details, enough to recall what this was.
I have a "Smart Wifi Lightbulb" which comes with an app to change its colors etc.
When I ran NMAP on the IP, it said that service=IRC was running on port 6668. I know that there are only a limited number of ports so there are bound to be devices that share ports that might not be what they are actually for.
As a test, I pulled up an IRC client and put in the IP and the PORT and it connected. It stays open for about 30 seconds and then disconnects.
Anything I should be worried about here or further things I should check into?
Short answer: Nothing to worry about regarding the port 6668, mostly.
The bulb you have is really common, sold under multiple brand names, and the IoT implementation can be found in plugs and switches, as well.
The bulb you have has an ESP8266 inside. It's controllable via a library called ESP8266MOD, I think. But I've always seen it referred to as Tuya, and the tuyapi, or python-brihome provide implementations that work using the UDP interface the device provides.
I happened upon your question looking for information on the Cree Connected Max bulb, which is definitely the same bulb. These bulbs are equipped with both WiFi and Bluetooth. The Bluetooth, I think, can be used for control of the bulb in general, but with mine, it was only used as a convenient way to talk to the bulb for the purpose of configuring WiFi security.
As for the mostly part...
I haven't taken the Cree protocol apart like I did the Ankuoo, but I poked at it a little bit this weekend. The biggest concern I had on the Ankuoo device, I think (5 years ago) was that when you sent the command querying bulb state/info, there was a large part of that packet which appeared to be encrypted. And, I think, the packet actually contained my SSID. There's just no good reason for them to send that out, and since I was able to perform every function of the app, and read every value the app displayed (along with several others), I didn't trust that data.
The good news is if you're concerned about the security of the device, you don't necessarily have to toss it.
My solution was to treat it as untrusted: I isolated my bulbs; they cannot talk outside of the subnet they are on which is reserved for IoT; my Home Assistant server can reach it, but it can't be seen from the subnet. I also created a separate SSID for it, with its own shared key. I allow broadcast from the bulb and traffic to the bulb. This makes all of the cloud features fail, but I configured Home Assistant to manage the bulb and simply control it through UDP broadcast.
And frankly, the user experience ends up being better this way. When I issue a command to the bulb, the UDP broadcast is picked up instantly. There's no round-trip to a Chinese[0] Command/Control server.
If the small company behind the product goes out of business, the bulbs are still controllable -- as far as they know, the company is out of business. [0] That sounds derogatory, but was simply meant as fact. With the cloud services enabled, my Cree and Ankuoo devices communicate exclusively with servers hosted in China, but I wouldn't care if they were hosted in the US.