TalkTalk TV box talking to other devices on the network - bad config in pfsense?

[firewalluser]

AMD64 2.2.4

I'll admit I'm a TalkTalk user, anyway every device is on its own seperate vlan, all vlans are isolated from each other except when they need to share a port for printing or network share and then a rule will created otherwise everthing is a default block including netbios in some cases, yet I found my TalkTalk tv box trying to connect to port 53 (DNS) on a honeypot I have lanside.

Whilst there was no explicit rule to block access to this honeypot, (why would there be), and despite the DHCP settings being correct for the vlan, why would pfsense give out information via the DHCP server on the vlan to suggest there would be a DNS server on another Vlan.

The only thing I can think of, is perhaps the TalkTalk tv box is using something like netbios to find out what other devices are being handled by pfsense and then trying to connect to them that way. This behaviour is only seen when I kill net access.

I'm not too happy to find my TalkTalk tv box snooping around my network, but does pfsense give out netbios info across all vlans, or something else for this TalkTalk tv box to attempting to connection to other devices on the network where there is no need to?

TIA

[David_W]

The only way to get any definitive and reliable answers is packet capture.

If your switch supports mirroring, mirror the TV box's port to another port and use Wireshark to capture the packets. You'll then be able to characterise the behaviour of the TV box.

[firewalluser]

Packet Capture is the conclusion I've come to as well which is what I'm in the process of doing atm.

However as I've just also had to have a new router from them as the HG533 with default username & password "admin" "admin" of all things bricked it two weeks ago when I reflashed the firmware to be sure it hadnt been compromised in a way like this http://www.theguardian.com/technology/2015/jan/12/lizard-squad-lizardstresser-hacked-home-routers  also makes a mockery of their claims they have excellent IT security considering their servers can remotely configure the router using TR069 https://en.wikipedia.org/wiki/TR-069

I know of one windows programmer who was in the programmers user group I ran, whose software does the billing for a telco here in the UK which suggests some level of contact to the phone system can be accessed via the windows platform as well. The SQL injection they are playing things down with is potentially dangerous as well, if its MS SQL server, as MS SQL server can effectively give your root or Session 0 on windows. Certainly encrypting the database is of little use if the hackers copied an encrypted table thats been decrypted and running in a view/table in memory. Being an old school ISAM DB programmer from many moons ago long before SQL servers even existed, database encryption is one of those age old problems as you need the speed which is why SQL Servers in general load things into memory in various sort orders instead of reading and writing from disk, especially considering windows file locking is notoriously slow and often resulted in files being locked. OpLocks is one such example of the hacks to the registry that needed to be done to make isam db writes reliable otherwise the windows network cache would overwrite data resulting in lost records (rows) amongst other things.

So this and other problems makes me very cautious in todays joined up world.

[firewalluser]

It just gets better with TalkTalk.

Trying to access https://myaccount.talktalk.co.uk/home/dashboard and I get

    (92) Protocol error (TLS code: SQUID_ERR_SSL_HANDSHAKE)

    Handshake with SSL server failed: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

Dig around as I think this is the year old Poodle exploit but cant find the /etc/squid/squid.conf to check if sslv3 is on or not but do find this thread

https://forum.pfsense.org/index.php?topic=100167.msg564656#msg564656

Dok sums it up nicely I think and ironically PCI wont find this problem as the link Dok uses doesnt handle sub uri's giving TalkTalk an A pass https://www.ssllabs.com/ssltest/analyze.html?d=myaccount.talktalk.co.uk/home/dashboard

So looks like a PCI fail as well.

I've attached a screenshot of the youview box attempting to access other vlans when its internet access is killed. Its setup to get its ip setting from the dhcp server, so either pfsense was misconfigured (unlikely considering how hard it is to force a different dns on it) or theres something up with the TalkTalk box. Talk Talk support claim what is seen in the picture is impossible, and I've checked it to make sure there is no left over secondary dns's servers even though its only ever been given one dns in its entire life span of a few years.

Is it possible this device has been hacked and being used to explore other devices on the network, yes I'd say it is considering you can watch movies online with it, the tv schedule comes from the internet and other things.