I would really like to know best practices for the firewall. I'm not sure what I can block.
TCP Attempted Information Leak DESTINATION 51.75.78.103:80 ET POLICY curl User-Agent Outbound
Every 10-15 seconds.
I've been looking these up on everything and most of it seems to be false positives, and that's just lan. This was one of the first things I looked at since it's happening so often. I couldn't find much, except:
Abstract. We show how to exploit side-channels to identify clients with-
out eavesdropping on the communication to the server, and without re-
lying on known, distinguishable traffic patterns. We present different
attacks, utilizing different side-channels, for two scenarios: a fully off-
path attack detecting TCP connections, and an attack detecting Tor
connections by eavesdropping only on the clients.
Our attacks exploit three types of side channels: globally-incrementing IP
identifiers, used by some operating systems, e.g., in Windows; packet pro-
cessing delays, which depend on TCP state; and bogus-congestion events,
causing impact on TCP’s throughput (via TCP’s congestion control
mechanism). Our attacks can (optionally) also benefit from sequential
port allocation, e.g., deployed in Windows and Linux. The attacks are
practical - we present results of experiments for all attacks in different
network environments and scenarios. We also present countermeasures
for these attacks
https://www.researchgate.net/publication/253954669_Spying_in_the_Dark_TCP_and_Tor_Traffic_AnalysisIt's an older paper so nothing new, but it's creepy seeing it in real time. I looked back at my firewall and saw that the ports I'm sending from are sequential, to the same ip listed above over and over. So I'm sending out http packets from sequential ports every 10-15 seconds. Surely this isn't right. It doesn't look like the other traffic.
The flaw that we identify is that a blind adversary is able to cause a TCP recipient an involuntary
reaction by sending arbitrary (spoofed) packets. We propose keeping a small
window of acceptable sequence numbers that may be processed. This window
resembles the receiver’s congestion window, but is more aggressive: while packets
outside the congestion window cause a duplicate acknowledgment (which we use
in the attacks described in Sections 3-5), packets that specify sequence numbers
outside the acceptable-window are silently discarded. The acceptable-window is
larger than the host’s congestion window and includes it. A congestion window
is usually up to 216 bytes, an acceptable-window that is twice as large, i.e., 217
bytes, will significantly degrade the attacker’s ability to conduct all the attacks
in this paper. Since the sequence number is 32 bits long, the attacker is required
to send ... times the number of packets to conduct similar attacks. How-
ever, this technique requires that the firewall will inspect the sequence numbers
in incoming TCP packets, which increases the packet processing overhead.
Ideally, I'd like to figure out how to block with pfsense rather than suricata. I just blocked that ip/port but I don't think it was the same ip yesterday. Any insights into best practices are appreciated.
