Dropping SYN with FIN flag set

Dropping SYN with FIN flag set

[James Miller]

Hi folks.. sorry if this is a really dumb question.. please don't flame me
too much.

Nessus is always alerting on  "Remote host does not discard TCP SYN packets
which have the FIN flag set".  What is the best way to close up this hole?
Is there a global rule I could setup or do I need to set this on a per rule
basis?

something like '-p tcp --tcp-flags SYN,FIN -j DROP'





Thanks,
Jim

Re: Dropping SYN with FIN flag set

[Chris Brenton]

On Tue, 2003-10-21 at 11:47, James Miller wrote:
>
> Nessus is always alerting on  "Remote host does not discard TCP SYN packets
> which have the FIN flag set".  What is the best way to close up this hole?

One of the nice things you get with iptables over many commercial
offerings is the flexibility to deal with stuff like this. ;-)

> something like '-p tcp --tcp-flags SYN,FIN -j DROP'

Here is what I do:

iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL SYN,ACK -j LOG
--log-prefix " SYNACK "
iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL SYN,ACK -j REJECT
--reject-with icmp-host-unreachable
iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL SYN,FIN -j LOG
--log-prefix " SYNFINSCAN "
iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL SYN,FIN -j REJECT
--reject-with icmp-host-unreachable
iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL FIN -j LOG
--log-prefix " FINSCAN "
iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL FIN -j REJECT
--reject-with icmp-host-unreachable
iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL NONE -j LOG
--log-prefix " NULLSCAN "
iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL NONE -j REJECT
--reject-with icmp-host-unreachable
iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL FIN,PSH,URG -j LOG
--log-prefix " NMAPXMAS "
iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL FIN,PSH,URG -j REJECT
--reject-with icmp-host-unreachable

I prefix these traffic patterns to make them easier to parse out of the
logs, and the reject the traffic with a host unreachable. I like using
type 3's rather than drops as it confuses the scanner on the other end
and many times shuts it down (ie. scanner gives up thing the host is not
on-line).

HTH,
C

Re: Dropping SYN with FIN flag set

[Jeffrey Laramie]

Chris Brenton wrote:

>Here is what I do:
>
>iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL SYN,ACK -j LOG
>--log-prefix " SYNACK "
>iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL SYN,ACK -j REJECT
>--reject-with icmp-host-unreachable
>iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL SYN,FIN -j LOG
>--log-prefix " SYNFINSCAN "
>iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL SYN,FIN -j REJECT
>--reject-with icmp-host-unreachable
>iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL FIN -j LOG
>--log-prefix " FINSCAN "
>iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL FIN -j REJECT
>--reject-with icmp-host-unreachable
>iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL NONE -j LOG
>--log-prefix " NULLSCAN "
>iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL NONE -j REJECT
>--reject-with icmp-host-unreachable
>iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL FIN,PSH,URG -j LOG
>--log-prefix " NMAPXMAS "
>iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL FIN,PSH,URG -j REJECT
>--reject-with icmp-host-unreachable
>  
>

Hey Chris -

I've taken a rudimentary stab at these kinds of rules with mixed success 
and your post brings up a couple of questions:

Here are the rules I'm using now:

# Chain to trap bad packets before they enter the system.
$iptables -A Bad_Packet -p tcp -m state --state INVALID -j LOG 
--log-level debug
$iptables -A Bad_Packet -p tcp -m state --state INVALID -j DROP
$iptables -A Bad_Packet -p tcp --tcp-flags SYN,ACK SYN,ACK -m state 
--state NEW
$iptables -A Bad_Packet -p tcp ! --syn -m state --state NEW -j LOG 
--log-level
$iptables -A Bad_Packet -p tcp ! --syn -m state --state NEW -j DROP

1.  These obviously are different from your rules. Are these rules 
useful or should I just replace them with rules similar to yours?

2.  I tried applying rules like these with -p all and I ended up 
trapping all kinds of local ICMP traffic and broke lots of things. 
Should I have these kinds of stateful rules for other protocols or 
doesn't that matter?

Jeff

Re: Dropping SYN with FIN flag set

[Chris Brenton]

On Tue, 2003-10-21 at 13:51, Jeffrey Laramie wrote:
>
> Hey Chris -

Greetings! :)

> I've taken a rudimentary stab at these kinds of rules with mixed success 
> and your post brings up a couple of questions:
>
> Here are the rules I'm using now:
> 
> # Chain to trap bad packets before they enter the system.
> $iptables -A Bad_Packet -p tcp -m state --state INVALID -j LOG 
> --log-level debug
> $iptables -A Bad_Packet -p tcp -m state --state INVALID -j DROP

On the up side, this combo should catch all the stuff I mention in my
rules far more efficiently as you are only using a single rule. On the
downside, you'll see a lot of false positives (like state table
time-outs during the FIN/ACK exchange) and it does not categorize the
flag combo for easy review later (as mine does). 

Also, are you trying to use --log-level to increase the amount of
detail? If so, that switch actually sets the Syslog facility level. You
can try using the IP or TCP options switch instead to get more detail.

> $iptables -A Bad_Packet -p tcp --tcp-flags SYN,ACK SYN,ACK -m state 
> --state NEW
> $iptables -A Bad_Packet -p tcp ! --syn -m state --state NEW -j LOG 
> --log-level
> $iptables -A Bad_Packet -p tcp ! --syn -m state --state NEW -j DROP

This should work (I have not tried it). I do similar except I don't use
-m and place the rules after the state table gets processed (same effect
except my way is dependent on the rule order not getting messed up). I
also prefix the SYN/ACK log entries with " SPOOFING_FALLOUT " to make
them easier to extract from my logs.

> 1.  These obviously are different from your rules. Are these rules 
> useful or should I just replace them with rules similar to yours?

I actually have a method to my madness. Each morning I have a cron job
kicks off to process the logs from the day before. The script has a ton
of entires similar to the following:

grep SYNFINSCAN cb5.txt > synfin-scan.txt
grep -v SYNFINSCAN cb5.txt > cb6.txt
grep FINSCAN cb6.txt > finscan.txt
grep -v FINSCAN cb6.txt > cb7.txt
grep NULLSCAN cb7.txt > nullscan.txt
grep -v NULLSCAN cb7.txt > cb8.txt
grep NMAPXMAS cb8.txt > nmapxmas.txt
grep -v NMAPXMAS cb8.txt > cb9.txt

Pretty easy to see what I'm doing. I'm leveraging the prefixing I
mentioned in my last post to parse each traffic pattern into its own
text file. This makes figuring out what happened in the logs far easier.
It also helps to catch slow scans. For example if someone tries a FIN
scan but only sends a probe every two hours, it still sticks out like a
sore thumb using this method of review.

Now with that said, the nice thing about a flexible tool is that you can
use it any way that makes the most sense to you. The above works for me,
your mileage may vary. ;-)

> 2.  I tried applying rules like these with -p all and I ended up 
> trapping all kinds of local ICMP traffic and broke lots of things. 

Humm. TCP is the only protocol (that I'm aware of) that actually uses
flags, so this would be hard to do with other transports. For example
you can't identify state with UDP, just direction and port. The problem
with logging all invalid this way is that you end up throwing everything
that does not hit a permitted port into the same bit bucket. For
example:

iptables -A FORWARD -i eth0 -p udp -s 0/0 --sport 1024:65535 -d 0/0
--dport 1433:1434 -j LOG --log-prefix " MS_SQL "
iptables -A FORWARD -i eth0 -p udp -s 0/0 --sport 1024:65535 -d 0/0
--dport 1433:1434 -j REJECT --reject-with icmp-host-unreachable
iptables -A FORWARD -i eth0 -p udp -s 0/0 --sport 500 -d 0/0 --dport 500
-j LOG --log-prefix " IPSEC_SCAN "
iptables -A FORWARD -i eth0 -p udp -s 0/0 --sport 500 -d 0/0 --dport 500
-j REJECT --reject-with icmp-host-unreachable
iptables -A FORWARD -i eth0 -p udp -d 0/0 --dport 135:139 -j LOG
--log-prefix " MS_CRAP "
iptables -A FORWARD -i eth0 -p udp -d 0/0 --dport 135:139 -j REJECT
--reject-with icmp-host-unreachable

Again, this just allows me to segregate all my traffic based on specific
patterns so its easier to review. I use grep to extract these entries in
a similar fashion to what I described about. 

To give you an idea how effective this is, on an average day I generate
70-80 MB worth of firewall log entries. Its not uncommon to have all of
this traffic, except for maybe 100 KB, extracted into its own file. This
means that I go from having 80 MB to 100 KB of log files that I actually
have to put my thinking cap on to review. The rest is done
automagically.

As for breaking ICMP and others, could be you ended up letting through
established traffic, but not related (related being ICMP type 3's, 4's,
5's and 11's). A quick review of your rules should show you if this is
the case.

HTH!
C

Re: Dropping SYN with FIN flag set

[Tom Marshall]

[-- Attachment #1: Type: text/plain, Size: 888 bytes --]

> I actually have a method to my madness. Each morning I have a cron job
> kicks off to process the logs from the day before. The script has a ton
> of entires similar to the following:
> 
> grep SYNFINSCAN cb5.txt > synfin-scan.txt
> grep -v SYNFINSCAN cb5.txt > cb6.txt
> grep FINSCAN cb6.txt > finscan.txt
> grep -v FINSCAN cb6.txt > cb7.txt
> grep NULLSCAN cb7.txt > nullscan.txt
> grep -v NULLSCAN cb7.txt > cb8.txt
> grep NMAPXMAS cb8.txt > nmapxmas.txt
> grep -v NMAPXMAS cb8.txt > cb9.txt

Don't know if you care or not, but you could do this much more efficiently
with perl.  If you don't want to do that, you can at least avoid the
tempfiles by using the surrounding spaces in your patterns, eg.

  grep " FINSCAN " logfile > finscan.txt

-- 
If you make people think they're thinking, they'll love you; but if you
really make them think they'll hate you.

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: Dropping SYN with FIN flag set

[Chris Brenton]

On Tue, 2003-10-21 at 15:29, Tom Marshall wrote:
>
> Don't know if you care or not, but you could do this much more efficiently
> with perl. 

I *totally* agree. I teach the SANS perimeter track (T2) and teach this
method of log review. While I can teach people how to use grep in about
10 minutes, perl takes a wee bit longer. Using the same method I teach
in class gives me a better chance to debug/improve/etc.

>  If you don't want to do that, you can at least avoid the
> tempfiles by using the surrounding spaces in your patterns, eg.
> 
>   grep " FINSCAN " logfile > finscan.txt

I like using temp files as it aids in debugging. Also, I kind of have to
use the temp files as I '-v' out everything I have a pattern for and
want to be able to see what ever is left (i.e. all the traffic I don't
create a match pattern for).

Thanks!
C

Re: Dropping SYN with FIN flag set

[Jeffrey Laramie]

Chris Brenton wrote:

>On Tue, 2003-10-21 at 13:51, Jeffrey Laramie wrote:
>  
>
>>Hey Chris -
>>    
>>
>
>Greetings! :)
>
>  
>
>>I've taken a rudimentary stab at these kinds of rules with mixed success 
>>and your post brings up a couple of questions:
>>
>>Here are the rules I'm using now:
>>
>># Chain to trap bad packets before they enter the system.
>>$iptables -A Bad_Packet -p tcp -m state --state INVALID -j LOG 
>>--log-level debug
>>$iptables -A Bad_Packet -p tcp -m state --state INVALID -j DROP
>>    
>>
>
>On the up side, this combo should catch all the stuff I mention in my
>rules far more efficiently as you are only using a single rule. On the
>downside, you'll see a lot of false positives (like state table
>time-outs during the FIN/ACK exchange) and it does not categorize the
>flag combo for easy review later (as mine does). 
>  
>

I only wish I had time to review my logs in that kind of detail. If I'm 
blocking the bad stuff, I'm happy!

>Also, are you trying to use --log-level to increase the amount of
>detail? If so, that switch actually sets the Syslog facility level. You
>can try using the IP or TCP options switch instead to get more detail.
>
>  
>

Actually it was a couple of previous posts, including one of your's, 
that got me thinking about logging. There were several questions about 
directing the iptables logs from /var/log/messages to a different file 
and the difficulty in splitting out the other kernel traffic. You 
answered one post described your system for handling logs and someone 
else (Jim from UCLA maybe?) answered another similar question by showing 
how to use log levels to split out iptables output from most other 
kernel logging. Not really knowing what I was doing, I thought, and I 
hacked , and I fixed what I hacked, and I thought some more, until I 
came up with my own system:

WARNING!  I have no clue! I mean it! Do not try this on a system you 
care about!

1.  I changed my sylog.conf to split off kernel.debug level messages to 
the iptables.log file. I chose debug level since a production kernel 
rarely uses it and I get (almost) pure iptables entries this way:

    # Iptables messages
    kern.=debug            -/var/log/iptables.log

    # save the rest in one file
    *.*;mail.none;news.none;kern.!=debug    -/var/log/messages

2.   In my filters I've created a separate rule for each of the major 
violations just like you've done. The only difference is I don't log the 
entry before dropping it. I already know what these entries are and I 
wouldn't know what to do with the logs anyway.

3.  I run:  iptables -L -n -v -x -Z > /var/log/iptables.report in a 
daily cron script.

4.  I modified my logrotate script to mail me the messages and 
iptables.log file each day before rotating the logs.

# Custom log rotation scripts.
/var/log/messages /var/log/iptables.log {
    rotate 7
    missingok
    daily
    mailfirst
    mail ServAdmn@Trans-Star.net
    create 0644 root root
    postrotate
        /etc/init.d/syslog reload
    endscript
}

Result:
I have 3 files to review each morning. The /var/log/messages file has 
pure kernel entries in it. If things are going ok this file is pretty 
short and boring. If there's a kernel problem it's real obvious. The 
iptables.report shows all the traffic by rule. This tells me what rules 
are catching the most crap and which rules aren't used at all. I don't 
have the detailed log that you get, but I have the metrics and that 
tells me if there's any unusual activity. What's left in the 
iptables.log file is the interesting stuff I want to look at: usually 
scans, packets that should be getting through but aren't, and an 
occasional bit of internal mischief   :-p

>  
>
>>2.  I tried applying rules like these with -p all and I ended up 
>>trapping all kinds of local ICMP traffic and broke lots of things. 
>>    
>>
>
>Humm. TCP is the only protocol (that I'm aware of) that actually uses
>flags, so this would be hard to do with other transports. For example
>you can't identify state with UDP, just direction and port. The problem
>with logging all invalid this way is that you end up throwing everything
>that does not hit a permitted port into the same bit bucket. For
>example:
>
>iptables -A FORWARD -i eth0 -p udp -s 0/0 --sport 1024:65535 -d 0/0
>--dport 1433:1434 -j LOG --log-prefix " MS_SQL "
>iptables -A FORWARD -i eth0 -p udp -s 0/0 --sport 1024:65535 -d 0/0
>--dport 1433:1434 -j REJECT --reject-with icmp-host-unreachable
>iptables -A FORWARD -i eth0 -p udp -s 0/0 --sport 500 -d 0/0 --dport 500
>-j LOG --log-prefix " IPSEC_SCAN "
>iptables -A FORWARD -i eth0 -p udp -s 0/0 --sport 500 -d 0/0 --dport 500
>-j REJECT --reject-with icmp-host-unreachable
>iptables -A FORWARD -i eth0 -p udp -d 0/0 --dport 135:139 -j LOG
>--log-prefix " MS_CRAP "
>iptables -A FORWARD -i eth0 -p udp -d 0/0 --dport 135:139 -j REJECT
>--reject-with icmp-host-unreachable
>
>Again, this just allows me to segregate all my traffic based on specific
>patterns so its easier to review. I use grep to extract these entries in
>a similar fashion to what I described about. 
>
>To give you an idea how effective this is, on an average day I generate
>70-80 MB worth of firewall log entries. Its not uncommon to have all of
>this traffic, except for maybe 100 KB, extracted into its own file. This
>means that I go from having 80 MB to 100 KB of log files that I actually
>have to put my thinking cap on to review. The rest is done
>automagically.
>
>As for breaking ICMP and others, could be you ended up letting through
>established traffic, but not related (related being ICMP type 3's, 4's,
>5's and 11's). A quick review of your rules should show you if this is
>the case.
>
>  
>
I'll take a look, thanks.

Jeff

Re: Dropping SYN with FIN flag set

[Chris Brenton]

On Tue, 2003-10-21 at 16:35, Jeffrey Laramie wrote:
>
> I only wish I had time to review my logs in that kind of detail. If I'm 
> blocking the bad stuff, I'm happy!

Actually, that's kind of the point. I used to use Nokia boxes at my
secure ISP and reviewing the logs was an all day event. By switching to
iptables I was collecting more information, but spending about 1/10 the
amount of time doing log review.

It takes time to setup your logging rules and the cron script I
described. Once its done however performing log review is a breeze.

Let me give you (yet another) example. My perimeter includes all my
accept rules for all legitimate FTP servers. After that, I have this set
of rules:

iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL SYN -d 0/0 --dport 21
-j LOG --log-prefix " FTP_SCAN "
iptables -A FORWARD -i eth0 -p tcp --tcp-flags ALL SYN -d 0/0 --dport 21
-j REJECT --reject-with icmp-host-unreachable

My script then parses the traffic like so:
grep FTP_SCAN cb19.txt > ftp-scan.txt
grep -v FTP_SCAN cb19.txt> cb20.txt

Now, I know on a daily basis this ftp-scan.txt file is normally 40-75 KB
in size (there are always script kiddies poking at FTP). When I see a
file size in this range, I don't even bother looking at it. If one day I
check the file and its 1 MB however, then I take the time to see if its
one persistent IP (in which case I ban it) or from a number of different
IPs (in which case there is a new tool and possibly a 0-day so I start
investigating what's going on and if my FTP servers need patching).

Log review really is a critical part of keeping your perimeter secure.
There are lots of tricks you can play to help minimize the time you
spend doing it.

> Actually it was a couple of previous posts, including one of your's, 
> that got me thinking about logging. There were several questions about 
> directing the iptables logs from /var/log/messages to a different file 
> and the difficulty in splitting out the other kernel traffic.

This is another "salt to taste" kind of thing. Some people do prefer to
dump the firewall log entries to their own file. I personally do not.

When I teach firewall log review my golden rule is "move aside
everything you expect, focus on the stuff you do not". For example the
script I keep mentioning pulls out all the traffic I expect my firewall
to record. The last temp file gets renamed "interesting.txt" and that's
the first file to get reviewed. Let's say someone SSH's to the box or
assumes root level privileges. These log entires will end up in that
"interesting.txt" file. Granted these are not true firewall log entries
but if someone has whacked this critical piece of my infrastructure, I
want to know about it ASAP. So leaving all the log entries in messages
helps to facilitate this process.

> I have 3 files to review each morning. The /var/log/messages file has 
> pure kernel entries in it. If things are going ok this file is pretty 
> short and boring. If there's a kernel problem it's real obvious. The 
> iptables.report shows all the traffic by rule.

This is totally cool. Again, one of the things thats nice about a
flexible tool is that everyone can customize it to suit the way they
like to review the data. :)

Thanks for the info!
C