Had my pfSense been compromised?

provels

So there is no outbound traffic to 103.240.140.10 from some device that creates this return Allow temp rule? Since all return traffic is allowed? Create a rule that allows (but logs) all traffic to 103.240.140.10? (LOL, ignore as needed! :)

johnpoz

To be honest I think this is log of traffic that IP or transport header is too short.. But not sure why its saying pass... But I don't think that traffic is actually being passed to anything, not even pfsense.

hulleyrob

Oct 13 09:14:13 pfSense filterlog: 4294967295,16777216,,0,pppoe0,short,pass,in,4,0x0,,245,35606,0,none,17,udp,27,103.240.140.10,IP_REMOVED,3266,990,7
Oct 13 09:14:13 pfSense filterlog: 4294967295,16777216,,0,pppoe0,short,pass,in,4,0x0,,245,35608,0,none,17,udp,27,103.240.140.10,IP_REMOVED,2427,389,7
Oct 13 09:14:13 pfSense filterlog: 4294967295,16777216,,0,pppoe0,short,pass,in,4,0x0,,245,35605,0,none,17,udp,27,103.240.140.10,IP_REMOVED,1862,1025,7
Oct 13 09:14:13 pfSense filterlog: 4294967295,16777216,,0,pppoe0,short,pass,in,4,0x0,,245,35607,0,none,17,udp,27,103.240.140.10,IP_REMOVED,570,995,7
Oct 13 09:14:13 pfSense filterlog: 4294967295,16777216,,0,pppoe0,short,pass,in,4,0x0,,245,35604,0,none,17,udp,27,103.240.140.10,IP_REMOVED,493,514,7
Oct 13 09:14:13 pfSense filterlog: 4294967295,16777216,,0,pppoe0,short,pass,in,4,0x0,,245,35609,0,none,17,udp,27,103.240.140.10,IP_REMOVED,2375,445,7
Oct 13 09:14:13 pfSense filterlog: 4294967295,16777216,,0,pppoe0,short,pass,in,4,0x0,,245,35602,0,none,17,udp,27,103.240.140.10,IP_REMOVED,162,546,7
Oct 13 09:14:13 pfSense filterlog: 4294967295,16777216,,0,pppoe0,short,pass,in,4,0x0,,245,35603,0,none,17,udp,27,103.240.140.10,IP_REMOVED,3871,547,7

Here are the entries from my log file.

johnpoz

So it seems these are short, ie something wrong with them... But the question is why are they getting logged as passed.. If they are short - they should just be dropped.

hulleyrob

@johnpoz if thats all it is it will be a relief as you saw on the screenshot above it looked like something had opened up all those ports.

What do I do now, is it worth reporting this somewhere for investigation?

johnpoz

I would hope @jimp or @Derelict might be able to give more details of these "short" log entries..

jimp

I can't remember the last time I saw one marked short. It might be a fragment.

johnpoz

But the question is why is marked pass?

jimp

If it's a fragment that is part of an existing connection, it would be passed. It might be that the state recently expired or was purged for some other reason so it was passed in but NAT didn't get applied, for example.

johnpoz

I doubt its frag, since that is a different counter - see my output from
pfctl -s info

above.

From the logs he lists I doubt its part of an existing connection.. From everything I find short should be dropped, so why is it logged as if it passed?

jimp

I'm not sure, unless it's being misinterpreted by filterlog.

If you can reproduce it reliably, you could capture the pflog output directly and pipe it through tcpdump (as described on https://www.openbsd.org/faq/pf/logging.html ) and see if that agrees.

johnpoz

I can not tried to reporduce it, but you could prob for sure feed short packets via packet creation tool to try and duplicated the problem.

But seems a few users are seeing a bunch of them - as you can see from my counters I have only ever seen 2 of them... But don't recall ever seeming in the the log as pass.. will keep an eye if that counter goes up and see what my log says since feeding all logs to syslog now for retention.. But if get a chance will try and duplicate a short to pfsense and see if can try and see what it logs.

ASIC

@jimp I have PfBlockerNG installed, and GeoIP Asia IP list, which includes 103.240.140.10, and it is applied as denied outbound connections on LAN, so there cannot be any existing connection to that IP.

NogBadTheBad

@ASIC said in Had my pfSense been compromised?:

103.240.140.10

Are you blocking Hong Kong ?

andy@mac-pro ~ % whois 103.240.140.10
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object

refer: whois.apnic.net

inetnum: 103.0.0.0 - 103.255.255.255
organisation: APNIC
status: ALLOCATED

whois: whois.apnic.net

changed: 2011-02
source: IANA

whois.apnic.net

% [whois.apnic.net]
% Whois data copyright terms http://www.apnic.net/db/dbcopyright.html

% Information related to '103.240.140.1 - 103.240.142.255'

% Abuse contact for '103.240.140.1 - 103.240.142.255' is 'abuse@clear-ddos.com'

inetnum: 103.240.140.1 - 103.240.142.255
netname: CTCL-HK
descr: ClearDDoS Technologies
country: HK
admin-c: CTCL1-AP
tech-c: CTCL1-AP
status: ASSIGNED NON-PORTABLE
mnt-by: MAINT-CTCL-HK
mnt-irt: IRT-CTCL-HK
last-modified: 2014-09-28T08:41:28Z
source: APNIC

irt: IRT-CTCL-HK
address: Flat C, 23/F, Lucky Plaza,, 315-321 Lockhart Road, Wan Chai, Hong Kong, Hongkong Hongkong 999999
e-mail: abuse@clear-ddos.com
abuse-mailbox: abuse@clear-ddos.com
admin-c: CTCL1-AP
tech-c: CTCL1-AP
auth: # Filtered
mnt-by: MAINT-CTCL-HK
last-modified: 2013-08-06T10:03:29Z
source: APNIC

role: CLEARDDOS TECHNOLOGY CO LIMITED administrator
address: Flat C, 23/F, Lucky Plaza,, 315-321 Lockhart Road, Wan Chai, Hong Kong, Hongkong Hongkong 999999
country: HK
phone: +86 755 8453 0553
fax-no: +86 755 8453 0553
e-mail: abuse@clear-ddos.com
admin-c: CTCL1-AP
tech-c: CTCL1-AP
nic-hdl: CTCL1-AP
mnt-by: MAINT-CTCL-HK
last-modified: 2013-08-06T10:03:28Z
source: APNIC

% This query was served by the APNIC Whois Service version 1.88.15-46 (WHOIS-UK4)

andy@mac-pro ~ %

ASIC

@NogBadTheBad said in Had my pfSense been compromised?:

@ASIC said in Had my pfSense been compromised?:

103.240.140.10

Are you blocking Hong Kong ?

Yes, I am.

NogBadTheBad

Just thought I'd check as some people think Hong Kong is China

hulleyrob

Its also interesting that we all saw clear DDOS technologies as passed in our logs and no-one else.

Ive not seen any other IP addresses associated with this problem.

jimp

I've looked through the pf source code and any place I see where PFRES_SHORT (short) reason gets set is only associated with the PF_DROP (block) action. So I'm not quite sure why it is being logged as a pass. The only difference is that when scrub is enabled, the code path that does packet normalization sets things slightly differently, so maybe that affects how the log entry is interpreted, but the packet is still dropped on that code path.

johnpoz

Is there anyway to make sure they are logged as blocked vs pass?

Yeah everything I was reading is short should be blocked, so not sure why they are logged as pass either.. Odd.. While I do have some hits in the counter for short via the info command.. I can not find anything in the logs on my syslog showing them... But then again those might of been before sending to syslog, and the counter has not gone up in the week since last did, still showing only 2.

If someone is seeing a lot of them, possible they could turn off scrub for testing to see if they are now logged blocked.

hulleyrob

@johnpoz ive not seen anymore since the day three of us all saw them.