Had my pfSense been compromised?
-
@provels haha yeah is windows phone even a thing anymore? Could be anything i suppose but I’m going to keep a more careful eye on it for a while.
-
@hulleyrob Glad you asked! I have 2 - 1 Nokia, 1 MS; one for use, one for backup. MS sold 2 and I bought them both! Going on 5 years, same battery, Windows 10, updates monthly. Makes calls and texts, takes pictures, navigation, in-a-pinch Internet, a few apps (not app-happy here). Best $30 (x2) I ever spent. Consumer Cellular, $25/month. I'll stop now.
-
514 is syslog, 995 is pop3 ssl, 546 and 547 is dhcpv6... 990 ftps
WTF why would any devices open those? 445 is smb over tcp.. 389 LDAP
Those are not unique to windows...But I would be concerned with stuff opening those up... Which is why you never run freaking UPnP... Its was a horrible idea from day one..
Why not just sniff on your interface for the UPnP ports and see what is hitting them.
-
Hi, I have exactly the same problem - weird incoming connections from the same ip (103.240.140.10). UPnP is disabled. No open WAN ports, no floating rules. Pfsense 2.4.4-RELEASE-p3 (amd64). I googled this IP and realize it has been blacklisted at some places:
http://sanyalnet-cloud-vps.freeddns.org/mirai-ips.txt
https://whatismyipaddress.eu/downloads/ip-blacklist.txt
I have only Windows 7 PC's in my LAN. They all were shut down when this traffic appear. Sorry for my bad English.
-
https://www.abuseipdb.com/check/103.240.140.10
But not why the traffic was passed. -
Your not even showing your rule Ids or description. For all we know you have an any any rule on your wan?
-
When I place the mouse over the green check on left on the rule, it shows "pass/0". When I click it opens a popup: "The rule that triggered this action is:" Nothing else.
-
Rule description is @4294967295.
-
Does anyone have an idea where the rule id comes from as it looks like we all have the same rule ID number creating these rules maybe this will give us an idea of where they are coming from?
Ideally there would be some logging or history but as everyone has said upnp is a bad idea for most people so i guess thats why it doesnt exist.
Also they are also 8 seconds apart in batches but this could be the time that the service runs each time?
-
So I just turned UPnP on - to test.. And then set my plex to use UPnP vs the static forward I have setup.
So I disabled my normal port forward.. Then enable UPnP
And I get this.
After doing a can you see me for the port listed in the UPnP status 21735
Is not coming up with that ID number.. A google for that ID and pfsense came up with this thread
https://forum.netgate.com/topic/128685/firewall-log-showing-strange-pass-entryCan we see the raw firewall logs for these entries. Like in that thread.
example - here is the raw entry for one of those passed via upnp
Oct 15 06:10:27 filterlog: 224,0,miniupnpd,0,igb1,match,pass,in,4,0x0,,42,13284,0,DF,6,tcp,60,52.202.215.126,192.168.9.10,58368,32400,0,S,2623792563,,26883,,mss;sackOK;TS;nop;wscaleYou can see from the log that miniupnpd there.. So lets see the raw for these entries.
From that other thread
Mar 25 14:42:05 pfSense filterlog: 4294967295,,,0,re0,short,pass,in,4,0x0,,239,10359,0,DF,6,tcp,36,105.212.87.78,[MYIPADDRESS],2123,23,-4,S,errormsg='[bad hdr length 20 - too long, > 16]',Not exactly sure what "short" means as the reason...
-
@johnpoz yeah sure i did look at those last night but couldnt see anything that looked much differant from in the screenshot but maybe you will see something i cannot. Will post as soon as i get home from work. Thanks to everyone for input and testing this.
-
Here is my raw filter log for this:
Oct 14 20:42:00 filterlog: 4294967295,,,0,pppoe0,short,pass,in,4,0x0,,241,53405,0,none,17,udp,27,103.240.140.10,[MYIPADDRESS],1810,1985,7 -
@ASIC said in Had my pfSense been compromised?:
short,
I have no idea what that means... Have never seen that in the logs before.
Found this;
reason res - the reason that action was taken. Possible reasons are match, bad-offset, fragment, short, normalize, memory, bad-timestamp, congestion, ip-option, proto-cksum, state-mismatch, state-insert, state-limit, src-limit and synproxy.But not sure what "short" actually means?
edit: Ok looks there have been some that match on short (2) - but still not actually finding anything that describes what it actually means
[2.4.4-RELEASE][admin@sg4860.local.lan]/root: pfctl -s info Status: Enabled for 30 days 22:17:00 Debug: Urgent Interface Stats for igb0 IPv4 IPv6 Bytes In 350478233746 69232705 Bytes Out 1405455628533 1128183040 Packets In Passed 466867557 311496 Blocked 8876 1 Packets Out Passed 999590646 1171599 Blocked 0 0 State Table Total Rate current entries 404 searches 3535810440 1323.2/s inserts 15778842 5.9/s removals 15778438 5.9/s Counters match 16542390 6.2/s bad-offset 0 0.0/s fragment 64 0.0/s short 2 0.0/s normalize 21 0.0/s memory 0 0.0/s bad-timestamp 0 0.0/s congestion 0 0.0/s ip-option 125 0.0/s proto-cksum 0 0.0/s state-mismatch 2834 0.0/s state-insert 0 0.0/s state-limit 0 0.0/s src-limit 0 0.0/s synproxy 0 0.0/s map-failed 0 0.0/s [2.4.4-RELEASE][admin@sg4860.local.lan]/root: -
-
@bchan said in Had my pfSense been compromised?:
4294967295
Maybe because 4294967295(Dec) is equal to FFFFFFFF(Hex).
-
Ok so from research so fare
short packets dropped
Is that that is suppose to mean.. but why does it say passed then?
-
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! :)
-
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.
-
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,7Here are the entries from my log file.
-
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.
