SYN+FIN packets and PF

With scrubbing turned on, the PF packet filter "normalizes" packets with the SYN+FIN flags set.  A tcpdump on both sides of the firewall shows the packet coming in with SYN+FIN, then passing into the network with only the SYN flag set.   With the same rules, a packet with SYN+RST gets dropped.


Why wouldn't the packet filter just drop this packet - is there any circumstance where a TCP packet would legitimately have both of those flags set?   And is this something we should block, or is the behaviour of stripping the FIN flag and passing the packet on acceptable?
VeexAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
I don't think SYN-FIN is a valid header option combination. It would mean "open a socket, and close it immediately without further exchange" - which is what UDP is for. The scrubbing just seems to correct that misconfiguration. With screening (if available), the packet should be dropped as part of an attack attempt.

IIRC SYN-FIN is used as a means to (maliciously) scan for specific devices by their specific responses, to further customize a more sophisticated attack if the device has known flaws.
0
VeexAuthor Commented:
Thanks Qlemo,

That's the impression I was under, however I'm trying to understand why PF would block one type of misconfigured packet, while allowing and correcting another type ( SYN+RST vs SYN+FIN).
0
nociSoftware EngineerCommented:
PF is Open/Free/Net-BSD..  so it may be the wrong tree.
Anyway:

SYN+FIN is invalid and should be blocked/dropped. It sometimes is sent by analyzing software to do finger printing on the OS that is running.
And it was an attack on systems (Christmas attack).

SYN+FIN   != UDP because no data can travel with SYN and or FIN packets.
[ besides having a complete different protocol field ].
0
Newly released Acronis True Image 2019

In announcing the release of the 15th Anniversary Edition of Acronis True Image 2019, the company revealed that its artificial intelligence-based anti-ransomware technology – stopped more than 200,000 ransomware attacks on 150,000 customers last year.

btanExec ConsultantCommented:
Hope this help @ http://www.openbsd.org/faq/pf/filter.html#synproxy

One should be careful with using flags -- understand what you are doing and why, and be careful with the advice people give as a lot of it is bad. Some people have suggested creating state "only if the SYN flag is set and no others". Such a rule would end with:

     . . . flags S/FSRPAUEW  bad idea!!

The theory is, create state only on the start of the TCP session, and the session should start with a SYN flag, and no others. The problem is some sites are starting to use the ECN flag and any site using ECN that tries to connect to you would be rejected by such a rule. A much better guideline is to not specify any flags at all and let PF apply the default flags to your rules. If you truly need to specify flags yourself then this combination should be safe:

. . . flags S/SAFR

While this is practical and safe, it is also unnecessary to check the FIN and RST flags if traffic is also being scrubbed. The scrubbing process will cause PF to drop any incoming packets with illegal TCP flag combinations (such as SYN and RST) and to normalize potentially ambiguous combinations (such as SYN and FIN).

Something the SYN is also to pass network security device policy checks e.g.

> A FIN scan sends TCP segments with the FIN flag set in an attempt to provoke a response (a TCP segment with the RST flag set) and thereby discover an active host or an active port on a host. Attackers might use this approach rather than perform an address sweep with ICMP echo requests or an address scan with SYN segments because they know that many firewalls typically guard against the latter two approaches—but not necessarily against FIN segments. The use of TCP segments with the FIN flag set might evade detection and thereby help the attackers succeed in their reconnaissance efforts.
0
skullnobrainsCommented:
most people nowadays tend to state that SYN+FIN packets are not legitimate. as far as i know, they are legitimate and will be properly handled by any tcp stack and most firewalls out there. but then, i've been blocking them on many production systems for years, and i never saw a situation in which it would break anything useful.

the freebsd kernel has featured a sysctl mib "tcp_block_synfin" or something similar for many years (sorry, i don't have the exact mib name but i assume it is easy to grep it from "sysctl -a" if you have a freebsd machine around)

it is easy to block in pf with a rule like
"block in from any to any proto tcp flags SF/SF"
... which should actually also work with either ipf or ipfw

---

if you're interested in such weird tcp packets, you probably should also take care of "fragmented" packets and "short" packets. a general rule of thumb is to block them for everything except for ssh sessions
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
VeexAuthor Commented:
Great response Skullnobrains;

The FreeBSD sysctl value is net.inet.tcp.drop_synfin: 1 which causes such packets to be dropped, UNLESS PF is enabled.   When PF is enabled, it "normalizes" the packet by stripping the FIN flag and leaving the SYN, allowing the packets to pass.

I've tested and verified this, and used a similar SF/SF flags block rule as you suggested which was effective.
0
skullnobrainsCommented:
thanks a lot for posting back. i was not aware of that behaviour with pf (i use ipf much more often on freebsd).

best regards
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Unix OS

From novice to tech pro — start learning today.