DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Security

OpenBSD Security Functionally paranoid!

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 29th August 2015
Peter_APIIT Peter_APIIT is offline
Shell Scout
 
Join Date: Jun 2008
Posts: 121
Smile Suspicious Tcpdump Traffic

Dear All,

Recently, I tried to monitor the traffic of my home router and i found out that there is suspicious block out traffic. Is this a sign of intruding or just a invalid block?

I had check the ip of intruding and is valid ip from us server.
Quote:
# tcpdump -netttr /var/log/pflog | grep 192.30.180.55 | more
tcpdump: WARNING: snaplen raised from 116 to 160
Aug 29 17:01:21.545940 rule 3/(match) block out on pppoe0: 60.53.42.139.3902 > 192.30.180.55.80: F 1636931384:1636931384(0) ack 3614876530 win 2048 <nop,nop,timestamp 513253558 0> (DF)
Aug 29 17:01:52.545695 rule 3/(match) block out on pppoe0: 60.53.42.139.5129 > 192.30.180.55.80: F 1496655121:1496655121(0) ack 4293757631 win 2048 <nop,nop,timestamp 4187575070 1427451936> (DF)
Aug 29 17:02:25.545377 rule 3/(match) block out on pppoe0: 60.53.42.139.3902 > 192.30.180.55.80: F 0:0(0) ack 1 win 2048 <nop,nop,timestamp 513253686 0> (DF)
Aug 29 17:02:56.545124 rule 3/(match) block out on pppoe0: 60.53.42.139.5129 > 192.30.180.55.80: F 0:0(0) ack 1 win 2048 <nop,nop,timestamp 4187575198 1427451936> (DF)
Aug 29 17:03:29.544827 rule 3/(match) block out on pppoe0: 60.53.42.139.3902 > 192.30.180.55.80: F 0:0(0) ack 1 win 2048 <nop,nop,timestamp 513253814 0> (DF)
Aug 29 17:04:00.544571 rule 3/(match) block out on pppoe0: 60.53.42.139.5129 > 192.30.180.55.80: F 0:0(0) ack 1 win 2048 <nop,nop,timestamp 4187575326 1427451936> (DF)
Aug 29 17:04:33.544305 rule 3/(match) block out on pppoe0: 60.53.42.139.3902 > 192.30.180.55.80: F 0:0(0) ack 1 win 2048 <nop,nop,timestamp 513253942 0> (DF)
Aug 29 17:05:04.544012 rule 3/(match) block out on pppoe0: 60.53.42.139.5129 > 192.30.180.55.80: F 0:0(0) ack 1 win 2048 <nop,nop,timestamp 4187575454 1427451936> (DF)
Aug 29 17:05:37.543716 rule 3/(match) block out on pppoe0: 60.53.42.139.3902 > 192.30.180.55.80: F 0:0(0) ack 1 win 2048 <nop,nop,timestamp 513254070 0> (DF)
Aug 29 17:06:08.543451 rule 3/(match) block out on pppoe0: 60.53.42.139.5129 > 192.30.180.55.80: F 0:0(0) ack 1 win 2048 <nop,nop,timestamp 4187575582 1427451936> (DF)
Aug 29 17:06:41.553169 rule 3/(match) block out on pppoe0: 60.53.42.139.3902 > 192.30.180.55.80: F 0:0(0) ack 1 win 2048 <nop,nop,timestamp 513254198 0> (DF)
Aug 29 17:07:12.562908 rule 3/(match) block out on pppoe0: 60.53.42.139.5129 > 192.30.180.55.80: F 0:0(0) ack 1 win 2048 <nop,nop,timestamp 4187575710 1427451936> (DF)
Aug 29 17:07:45.562602 rule 3/(match) block out on pppoe0: 60.53.42.139.3902 > 192.30.180.55.80: R 1:1(0) ack 1 win 0 (DF)
Kindly explain on this.
Reply With Quote
  #2   (View Single Post)  
Old 29th August 2015
ocicat ocicat is offline
Administrator
 
Join Date: Apr 2008
Posts: 3,318
Default

Quote:
Originally Posted by Peter_APIIT View Post
Kindly explain on this.
Please provide the following:
  • The output of:

    $ sysctl kern.version
  • Please post your complete ruleset.

Last edited by ocicat; 29th August 2015 at 10:19 AM. Reason: add versioning to request
Reply With Quote
  #3   (View Single Post)  
Old 29th August 2015
kpa kpa is offline
Port Guard
 
Join Date: Jul 2015
Posts: 18
Default

It's harmless, see:

https://doc.pfsense.org/index.php/Wh...ate_connection

The blocked traffic is going to TCP port 80 and the packets have the FIN (F) flag on. That is strong hint that they are very likely the last packets of connections that were torn down prematurely by the packet filter and the last FIN packets are then counted as "out of state" and blocked.
Reply With Quote
  #4   (View Single Post)  
Old 2nd September 2015
Peter_APIIT Peter_APIIT is offline
Shell Scout
 
Join Date: Jun 2008
Posts: 121
Default

Quote:
Originally Posted by ocicat View Post
Please provide the following:
  • The output of:

    $ sysctl kern.version
  • Please post your complete ruleset.
Kernel Version:
Quote:
kern.version=OpenBSD 5.7 (GENERIC.MP) #767: Sun Mar 8 11:04:48 MDT 2015
deraadt@i386.openbsd.org:/usr/src/sy...ile/GENERIC.MP
Complete Ruleset:
Quote:
ext_if="fxp0"
int_if="vr0"
local_net="172.16.1.0/24"
localhost="127.0.0.1"

www="{80, 443}"
squid_intercept="3129"

tcp="{80,443}"
udp="{53,123}"

set skip on lo
set loginterface pppoe0
set debug err
set block-policy drop
set state-policy if-bound
set reassemble yes

set state-defaults pflow
set optimization aggressive

set timeout interval 2
set timeout frag 7

set timeout {tcp.first 10, tcp.established 18000, tcp.opening 3, tcp.closing 10, tcp.finwait 10, tcp.closed 10,
udp.first 10,udp.single 10,udp.multiple 20,icmp.first 10,icmp.error 5,other.first 20,other.single 18,other.mul
tiple 30}

set limit {states 20000, src-nodes 20000, frags 1000}

match on pppoe0 scrub (reassemble tcp,random-id,no-df,max-mss 1440,min-ttl 64)
match out on pppoe0 inet from !(egress:network) to any nat-to (pppoe:0)

antispoof log for {$ext_if,$int_if}

block drop log

pass out on {pppoe0,$ext_if,$int_if} inet proto tcp modulate state
pass out on {pppoe0,$ext_if,$int_if} inet proto udp keep state
pass out on {pppoe0,$ext_if,$int_if} inet proto icmp all icmp-type echoreq keep state

#No Proxy

#Allow internal lan enter gateway
#pass in log on $int_if inet proto tcp from any to any port $tcp modulate state (max 40,source-track rule,max-s
rc-nodes 40,max-src-states 40,max-src-conn 30,max-src-conn-rate 20/20)

#squid intercept
pass in quick on $int_if proto tcp from $local_net to any port $www divert-to $localhost port $squid_intercept
pass out quick inet from $local_net divert-reply
By the way, here is the latest block out tcpdump which shows the destination IP address is belongs to my ISP(1.9.57.44, 1.9.57.157,1.9.57.247)

Quote:
Sep 02 20:51:42.428822 rule 3/(match) block in on pppoe0: 165.254.27.99.80 > 115.133.211.214.18171: S 638590200:638590200(0) ack 1190877752 win 14600 <mss 1460> (DF) [tos 0x8]
Sep 02 20:52:04.811605 rule 3/(match) block in on pppoe0: 162.244.35.24.42657 > 115.133.211.214.21320: S 4249006112:4249006112(0) win 65535
Sep 02 20:53:10.657874 rule 3/(match) block in on pppoe0: 42.99.254.160.80 > 115.133.211.214.18171: S 264356092:264356092(0) ack 1190877752 win 14600 <mss 1460> (DF)
Sep 02 20:54:30.499253 rule 3/(match) block out on pppoe0: 60.48.77.44.0 > 1.9.57.247.443: FP 3485237390:3485237513(123) ack 1019492554 win 2048 <nop,nop,timestamp 2999664311 401604807> (DF)
Sep 02 20:55:07.886939 rule 3/(match) block in on pppoe0: 118.161.247.142.4890 > 60.48.77.44.25: S 693095165:693095165(0) win 65535 <mss 1440,nop,nop,sackOK> (DF)
Sep 02 20:55:10.778957 rule 3/(match) block in on pppoe0: 118.161.247.142.4890 > 60.48.77.44.25: S 693095165:693095165(0) win 65535 <mss 1440,nop,nop,sackOK> (DF)
Sep 02 20:55:14.838638 rule 3/(match) block out on pppoe0: 60.48.77.44.0 > 1.9.22.221.443: FP 3833208431:3833208554(123) ack 187433726 win 2048 <nop,nop,timestamp 1676886394 1225966772>
Sep 02 20:55:16.789695 rule 3/(match) block in on pppoe0: 118.161.247.142.4890 > 60.48.77.44.25: S 693095165:693095165(0) win 65535 <mss 1440,nop,nop,sackOK> (DF)
Sep 02 20:55:34.498240 rule 3/(match) block out on pppoe0: 60.48.77.44.0 > 1.9.57.247.443: FP 0:123(123) ack 1 win 2048 <nop,nop,timestamp 2999664439 401604807>
Sep 02 20:55:35.198254 rule 3/(match) block out on pppoe0: 60.48.77.44.0 > 173.194.120.138.443: FP 2115712045:2115712168(123) ack 2256776203 win 2048 <nop,nop,timestamp 740998892 1791702893> (DF)
Sep 02 20:55:35.198441 rule 3/(match) block out on pppoe0: 60.48.77.44.0 > 1.9.57.157.443: FP 2773787168:2773787291(123) ack 969532157 win 2048 <nop,nop,timestamp 2107601466 3454701885> (DF)
Sep 02 20:55:37.359272 rule 3/(match) block in on pppoe0: 198.46.141.130.37402 > 60.48.77.44.123: [len=8] v2 res2 strat 0 poll 3 prec 42 (DF)
Sep 02 20:55:48.678275 rule 3/(match) block out on pppoe0: 60.48.77.44.0 > 1.9.57.247.443: FP 424208711:424209978(1267) ack 423617941 win 2048 <nop,nop,timestamp 2306166214 4072680920> (DF)
Sep 02 20:55:59.088108 rule 3/(match) block out on pppoe0: 60.48.77.44.0 > 1.9.57.44.80: FP 2781495408:2781495837(429) ack 637133820 win 2048 <nop,nop,timestamp 2500877741 3042542058>
Sep 02 20:55:48.678275 rule 3/(match) block out on pppoe0: 60.48.77.44.0 > 1.9.57.247.443: FP 424208711:424209978(1267) ack 423617941 win 2048 <nop,nop,timestamp 2306166214 4072680920> (DF)
Sep 02 20:55:59.088108 rule 3/(match) block out on pppoe0: 60.48.77.44.0 > 1.9.57.44.80: FP 2781495408:2781495837(429) ack 637133820 win 2048 <nop,nop,timestamp 2500877741 3042542058>
Sep 02 20:56:18.837798 rule 3/(match) block out on pppoe0: 60.48.77.44.0 > 1.9.22.221.443: FP 0:123(123) ack 1 win 2048 <nop,nop,timestamp 1676886522 1225966772> (DF)
Sep 02 20:56:38.497563 rule 3/(match) block out on pppoe0: 60.48.77.44.0 > 1.9.57.247.443: FP 0:123(123) ack 1 win 2048 <nop,nop,timestamp 2999664567 401604807>
Sep 02 20:56:39.197593 rule 3/(match) block out on pppoe0: 60.48.77.44.0 > 173.194.120.138.443: FP 0:123(123) ack 1 win 2048 <nop,nop,timestamp 740999020 1791702893>
Sep 02 20:56:39.198050 rule 3/(match) block out on pppoe0: 60.48.77.44.0 > 1.9.57.157.443: FP 0:123(123) ack 1 win 2048 <nop,nop,timestamp 2107601594 3454701885>
Sep 02 20:56:52.677692 rule 3/(match) block out on pppoe0: 60.48.77.44.0 > 1.9.57.247.443: FP 424208711:424209978(1267) ack 423617941 win 2048 <nop,nop,timestamp 2306166342 4072680920>

Please provide some explanation on this. Thanks you very much.
Reply With Quote
  #5   (View Single Post)  
Old 2nd September 2015
Peter_APIIT Peter_APIIT is offline
Shell Scout
 
Join Date: Jun 2008
Posts: 121
Default

Quote:
Originally Posted by kpa View Post
It's harmless, see:

https://doc.pfsense.org/index.php/Wh...ate_connection

The blocked traffic is going to TCP port 80 and the packets have the FIN (F) flag on. That is strong hint that they are very likely the last packets of connections that were torn down prematurely by the packet filter and the last FIN packets are then counted as "out of state" and blocked.
I'm not really understand the explanation. Please explain further regard the three way handshake scenario. Thanks.
Reply With Quote
  #6   (View Single Post)  
Old 2nd September 2015
kpa kpa is offline
Port Guard
 
Join Date: Jul 2015
Posts: 18
Default

Quote:
Originally Posted by Peter_APIIT View Post
I'm not really understand the explanation. Please explain further regard the three way handshake scenario. Thanks.

Did you read the linked document? This happens at the connection tear down phase, not during the three way handshake that is used to establish connections. It's most often caused by lost FIN packets that get retransmitted (remember TCP actively corrects errors such as lost packets) and the retransmitted packets arrive late because the connection is slow/laggy (the reason why the FIN packets got lost in the first place) and the packet filter has already decided to remove the states associated with the connection. The retransmitted FIN packets will be then rejected because there is no state matching them.
Reply With Quote
  #7   (View Single Post)  
Old 2nd September 2015
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Peter, I noticed two things:
  1. You are using the -release kernel, so you have not applied all errata patches, as advised last week. Patch 006 is a security fix for the -release kernel.
    Quote:
    Originally Posted by jggimi View Post
    ...I know that you want to "harden" your OpenBSD installation. Your first step towards actually doing that is to apply fixes for known issues...
  2. Your decision to provision aggressive optimization in PF is the reason these packets are blocked. I will repeat the same advice I gave you one month ago.
    Quote:
    Originally Posted by jggimi View Post
    If you don't know what a knob does, please don't touch it.

Last edited by jggimi; 2nd September 2015 at 05:40 PM. Reason: typo, clarity
Reply With Quote
  #8   (View Single Post)  
Old 3rd September 2015
kpa kpa is offline
Port Guard
 
Join Date: Jul 2015
Posts: 18
Default

Quote:
Originally Posted by jggimi View Post
Peter, I noticed two things:
  1. Your decision to provision aggressive optimization in PF is the reason these packets are blocked. ]
Good catch but it's not the sole reason for those packets appearing in the log. It does contribute to their frequency though with aggressive timeouts that clean up dangling states much quicker than with the normal timeouts. These log entries show up even with conservative timeouts but very rarely.
Reply With Quote
  #9   (View Single Post)  
Old 3rd September 2015
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

OK. But these would be far less likely to appear in Peter's logs. And apparently, he is still searching for the elusive, phantom hacker rather than applying his efforts to eliminating known security issues.

And he is apparently copying and pasting things he discovers on the Internet, without understanding the implications.

There is a different Peter: Peter Hansteen, the author of The Book of PF. He teaches PF tutorials worldwide, and has been doing so for many years. Mr. Hansteen always starts these sessions by having his audiences read the following text out loud. Our Peter here has likely never seen this:
Code:
The Pledge of the Network Admin

This is my network. 

It is mine 
or technically my employer's, 
it is my responsibility 
and I care for it with all my heart

there are many other networks a lot like mine,

but none are just like it.

I solemnly swear 

that I will not mindlessly paste from HOWTOs.

Last edited by jggimi; 3rd September 2015 at 12:21 PM. Reason: typo
Reply With Quote
Old 3rd September 2015
blackhole's Avatar
blackhole blackhole is offline
Spam Deminer
 
Join Date: Mar 2014
Posts: 316
Default

Quote:
Originally Posted by jggimi View Post
Code:
that I will not mindlessly paste from HOWTOs.
+1

Which aside from bad practice, doesn't make much sense considering Peter_APIIT's goal of increasing security beyond a default installation.

Copying and pasting from wikis/forums/howtos is pretty much like saying "I fully trust <some random blogger> on the web with my security". You are not actually learning the system yourself , but instead are relying on others, copying their configurations and reproducing their errors on your system.

Howtos do have a place, if they're educational, but receipe book style, "3 1/2 lbs of flour, two eggs, 2 cups of water and a blast of hot air - and oila you have an OpenBSD router with NAT!" type of thing does not help. It's great while it works, then when things go wrong you're adrift without a paddle... resorting to forums and reposting your copypasta configs - leaving it to others to try and untangle spaghetti...

Running the -release kernel is also at odds with the aims of someone so security focused. The errata patches are going to bite you in the arse continually. Until you can show that these have been applied, you will most likely not be taken seriously. 5.7 was released on 01/05/15. By my reckoning there are 13 patches to apply to 5.7-release. Three of those are kernel patches and you have applied none at all.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
understanding tcpdump frcc OpenBSD Security 3 11th April 2013 10:10 PM
tcpdump package bsdnewbie999 OpenBSD Packages and Ports 6 30th March 2009 05:24 PM
i would like to know about tcpdump chamnanpol FreeBSD General 8 17th September 2008 11:00 AM
Help with tcpdump file brokensilence General software and network 2 10th July 2008 03:45 PM


All times are GMT. The time now is 05:09 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick