Hello community.
After the announcement of the security hole in our devices we immediately updated the majority of our clients routers.
Unfortunately some devices were not updated as they are managed by the customers themselves.
So last night i decided to do a global check for any compromised devices. i've found 7 devices and informed the customers to
take actions.
I created some rules in forward chain to spot the traffic designated to port 4145 TCP .. which was the SOCKS modified port.. to find the hacked devices..
and i also created rules to find out the SRC IPs the traffic was originated from.
Next thing to do was to create a drop rule to stop traffic FROM "attackers" TO "hacked" devices.

Here comes the funny part.
Google Ips (8.8.8.8, 8.8.4.4) appeared in my list therefore any inbound traffic was dropped causing some problems to DNS resolve requests etc.

Port 4145 TCP is used for a vvr-control service or something.
My questions to the community are these.

1) My best guess is that traffic from google ips have had to be forged to bypass firewalls.
What is your opinion on this?

2) Even though the devices were patched .. and any visible modifications were undone .. I still track traffic on port 4145 (40b packets, Ack.Rst) and it got me thinking..
Could it be that the "hack" created further modifications that are invisible to user and the only way to be sure is to use NetInstall and start over? This traffic has to somehow
be triggered and it seems i cant find a legit reason. I also used packet sniffer to analyze traffic on wireshark but didnt find anything major there.

What do you think about that?

This post is more of exchanging opinions rather than solving a problem.
Did anyone else had a similar situation and what actions you have taken?

Traffic above the reserved ports (0-1024) can be attributed to ephemeral port use. While most OSes generally use the higher end of available ports, there's nothing stopping them from using 1025-65535 as ephemeral port numbers.

In which direction do ACK packets flow (assuming RSTs go in the other direction)? If they originate from internet and target sanitized devices, then they can be explained as connection resumption attempts that are rejected (not dropped). As if the other end still considered connection established.

@RC1H: it used to be this way. However, "service" ports below 1024 should be assigned to particular protocol (if my memory serves me right by IANA but I may well be wrong) and many of app developers tend to skip this procedure especially if their app doesn't use "open" protocol for communication. Many modern apps use well known ports above 1023 as service ports. Examples are TCP ports 1433 by MS SQL and 5432 by PostgreSQL just to name a couple.

Indeed many OSes require non-trivial app permissions when app tries to use "low" port while high ports can be used by any app without restrictions. I believe most of hackers have full control over their "tools" and this limitation should not present any problem whatsoever.

I think you misunderstand, this isn't about services listening on high ports.

Say for example client on the network want to connect to Google DNS, 8.8.8.8 port 53. Their OS has to pick a port on the system to send the query, and to which replies are sent, for example maybe it picks 192.168.88.10 port 4145 as the source port for the query. Then it sends the query to 8.8.8.8 port 53, Google DNS replies to 192.168.88.10 (ignoring NAT for now) port 4145... and now you've accidentally blacklisted Google.

Blacklisting on UDP traffic should not be included in any firewall rules ever, because UDP is connectionless and easily spoofed.

Blacklisting on TCP traffic should only occur for SYN attempts (connection state new) to specific ports, otherwise you risk blacklisting randomly when the OS picks a port that happens to coincide with a blacklisted one.

I mostly agree with you. I was just emphasizing that ports above 1023 need not be for temporary usage. It is not clear to me what kind of traffic has OP observed and hence my questions. He did explicitly mention TCP though.

Then it sends the query to 8.8.8.8 port 53, Google DNS replies to 192.168.88.10 (ignoring NAT for now) port 4145... and now you've accidentally blacklisted Google.

Blacklisting on UDP traffic should not be included in any firewall rules ever, because UDP is connectionless and easily spoofed.

Blacklisting on TCP traffic should only occur for SYN attempts (connection state new) to specific ports, otherwise you risk blacklisting randomly when the OS picks a port that happens to coincide with a blacklisted one.

Good point my friend..BUT ... i'm not using google for DNS resolving...neither my clients on the network.. What i mean is that there is no possible way to send dns requests to google ips .. with connection originating from this specific router or any other router in the internal network.
So .. that was a good hypothesis but unfortunately thats not the case.

I also strongly agree that inbound and forward traffic should be "firewalled" on syn packets. That was a good point.

Hi Cableguy, you lost me when you said you didnt have control of individually managed routers. So how did you manage to change their FW rules and see their traffic??

2) Even though the devices were patched .. and any visible modifications were undone .. I still track traffic on port 4145 (40b packets, Ack.Rst) and it got me thinking..
Could it be that the "hack" created further modifications that are invisible to user and the only way to be sure is to use NetInstall and start over? This traffic has to somehow
be triggered and it seems i cant find a legit reason. I also used packet sniffer to analyze traffic on wireshark but didnt find anything major there.

I know it's old thread but anyway:
My router was hacked and found this Disable ip socks:

nabilx, this has been discussed many times already. Yes, disable socks, fix the firewall (it also could be modified) and make sure you change your passwords. And run the latest 6.43

Normis, what about 'long-term' version, the last one is 6.42.11, does it provide the same security, performance and stability features like 6.43.8 (Stable)? Is it safe against port 4145 breach?