simple-scan-3.34.2-1.82 Vendor: SUSE LLC brscan4 - Brother Scanner Driver Brother sane backend Driver We are in Norway. App attempts to contact 46.50.57.49 when initiating a document scan for no apparent reason (netname: PT-TMN-201012 descr: MEO Mobile Customers - Portugal). App or driver issue ? Malware/privacy concern ? Ideas on how to proceed appreciated.
Have you executed the appropriate “brsaneconfig” configuration tool?
- In your case, possibly “brsaneconfig4” …
Something not right for sure…
Report back with output from
scanimage -L
and
brsaneconfig4 -q
Thank you both for the response.
This is a local network (only/wired/fixed IP) connected printer/scanner (Brother MFC-J5910-DW) which we have been using for years with the exact same driver (stored locally/checked OK with clamav), and “brsaneconfig4" reveals no surprises or changes (details below). Event first registered after recent clean Leap 15.3 install.
scanimage -L
device `brother4:net1;dev0' is a Brother *MFC-J5910-DW MFCJ5910DW
brsaneconfig4 -q | grep 5910DW
21 "MFC-J5910DW"
0 MFC-J5910-DW "MFCJ5910DW" I:192.168.120.10
Digging deeper it seems like (firewall log) the event is actually a reverse DNS lookup; 46.50.57.49.in-addr.arpa
Looks like someone wants to know the inside of our net…?
Digging into “46.50.57.49” it seems that, the DNS authority is “ripe.net” which seems to be registered with “gandi.net” which has a French telephone number.
- So, yes, something somewhere, has possibly been configured to use that IP address.
You may have to use a tool such as WireShark or Tcpdump to find out which data stream is trying to access that address.
The lookup of 46.50.57.49.in-addr.arpa is about the IP address 49.57.50.46, not about 46.50.57.49.
henk@boven:~> nslookup 49.57.50.46
** server can't find 46.50.57.49.in-addr.arpa: NXDOMAIN
henk@boven:~>
Regardless, you’ll still have to perform a network trace to discover which data stream is triggering the reverse-lookup …
Not a pro on this sort of tracing, but did a simple check yesterday (actually several different checks, but nothing that gave any meaning to this issue).
Sequence: tcpdump > simple-scan > initiated an image-scan - bold parts might be of relevance ?
tcpdump -vv -i eth2 port 53
IP (tos 0x0, ttl 64, id 19132, offset 0, flags [DF], proto UDP (17), length 70)
localhost.ourdomain.59650 > firewall.ourdomain.domain: [udp sum ok] 60403+ PTR? 46.50.57.49.in-addr.arpa. (42)
IP (tos 0x0, ttl 64, id 9238, offset 0, flags [none], proto UDP (17), length 129)
firewall.ourdomain.domain > localhost.ourdomain.59650: [udp sum ok] 60403 NXDomain q: PTR? 46.50.57.49.in-addr.arpa. 0/1/0 ns: 57.49.in-addr.arpa. SOA g.dns.kr. inverse.nic.or.kr. 2022031000 21600 900 604800 43200 (101)
IP (tos 0x0, ttl 64, id 19508, offset 0, flags [DF], proto UDP (17), length 70)
localhost.ourdomain.crestron-cip > firewall.ourdomain.domain: [udp sum ok] 2473+ PTR? 46.50.57.49.in-addr.arpa. (42)
IP (tos 0x0, ttl 64, id 9837, offset 0, flags [none], proto UDP (17), length 129)
firewall.ourdomain.domain > localhost.ourdomain.**crestron-cip**: [udp sum ok] 2473 NXDomain q: PTR? 46.50.57.49.in-addr.arpa. 0/1/0 ns: 57.49.in-addr.arpa. SOA** g.dns.kr. inverse.nic.or.kr.** 2022031000 21600 900 604800 43200 (101)
IP (tos 0x0, ttl 64, id 56099, offset 0, flags [DF], proto UDP (17), length 71)
Only what I believe might be relevant shown (long dump). Repeated a few times with same result. No indications of other related Internet traffic. IPs now temporary blocked in perimeter FW.
Removed the driver, installed driver for an Epson pro scanner and tested simple scan - no reverse DNS lookups or other oddities = Brother backend/driver issue.
Downloaded and installed the latest driver from Brother (0.4.11-1) with same strange result as previous driver (0.4.6-1).
Sent a query to Brother about this behavior - will revert here if any sensible reply.
It seems that, the Brother driver tries to contact something in South Korea – which is strange – Brother is a Japanese company.
- Does the content of the Brother PPD file – a text file – reveal anything?
Nothing obviously wrong or strange in the Brother PPD file or any readable files within the driver package. A quick package capture on the perimeter FW reveal nothing more in this respect. The highlighted crestron-cip is referred in
cat /etc/services | grep crestron
[FONT=monospace]**crestron**-cip 41794/tcp # Crestron Control Port [Ed_Ranney]
**crestron**-cip 41794/udp # Crestron Control Port [Ed_Ranney]
**crestron**-ctp 41795/tcp # Crestron Terminal Port [Ed_Ranney]
**crestron**-ctp 41795/udp # Crestron Terminal Port [Ed_Ranney]
**crestron**-cips 41796/tcp # Crestron Secure Control Port [Crestron_Electronics] [Manish_Talreja]
**crestron**-ctps 41797/tcp # Crestron Secure Terminal Port [Crestron_Electronics] [Manish_Talreja][/FONT]
but no immediate activities on those ports upon scanning. Can not see that we are using any SW/HW from Crestron (unless used as a sub-supplier to Brother), so that’s a bit strange.
Ideas on how to proceed ?
“Brother” isn’t mentioned anywhere in ‘/etc/services’ …
- Is the Brother Printer/Scanner a network device or, physically connected (USB or Printer cable) to the openSUSE system?
A local network (only/wired/fixed IP) connected printer/scanner…
If the Brother MFC box (which can print and scan and whatever) is a network device then, if it’s “calling home” it’s doing that on it’s own – with no involvement by the openSUSE system(s).
- If the openSUSE systems are causing the Name Resolution traffic then, it’s something installed on those systems –
Possibly the Brother scanner software – which may or, may not, be Open Source …
[HR][/HR]If we can inspect the code then, we know which functions are present in the (compiled) application …
Yes - as previously mentioned the activity (reverse DNS look-ups) seems to be triggered by the Brother driver/back-end as it’s not occurring with other drivers (e.g. Epson). The device is not allowed Internet access and the host machine that runs the SW and triggers the events is only allowed port 53 access to a local DNS server (UTM), so we do believe to have this somehow under control. Would still be nice to nail down the cause for others to be aware. Hopefully Brother will revert to our request with some useful explanations.