Had my pfSense been compromised?
-
look in your full rule set for what that ID number matches up with.
-
whois 103.240.140.10
inetnum: 103.240.140.1 - 103.240.142.255
netname: CTCL-HK
descr: ClearDDoS Technologies
country: HKIt sounds like a web security company.
-
I'm talking about your alias. Not the IP.
-
I have checked the table values for this alias and they all resolve correctly to 192.168.x.x
-
@bchan said in Had my pfSense been compromised?:
all resolve correctly to 192.168.x.x
LAPTOP-1CGD66U4 resolves to 192.168.x.x? Even on pfsense itself? Its resolvers?
-
-
@johnpoz said in Had my pfSense been compromised?:
pfctl -vvsr
pfctl -vvsr | grep 4294967295
return nothing. -
Then the rule was deleted, make sure your grep is working by using a ID in your command that you see when just looking at the output.
Are you currently seeing logs for this?
-
@johnpoz said in Had my pfSense been compromised?:
Then the rule was deleted, make sure your grep is working by using a ID in your command that you see when just looking at the output.
Are you currently seeing logs for this?
grep works for other id e.g. the teamviewer logger.
I have 2 WANs for months. This incident was the first time I saw incoming traffic to WAN2 and were logged.
As you can see from my rules, I don't have anything that will log incoming traffic for WAN2. -
Do you have UPnP enabled? Do you have it set to use WAN2, and to log connections?
That's the most likely explanation.
-
That would be my guess as well... You might be able to glean a bit more info by looking at the raw log in output.
-
When I manually trigger something like that (for example, open Deluge, go into settings, and trigger a port test), I get a similar log message with a random-ish ID.
Since the UPnP rules don't have a description, and have random IDs, and are probably short-lived, they wouldn't have a visible description in the logs even if you caught them when they were active.
-
@jimp said in Had my pfSense been compromised?:
Do you have UPnP enabled?
No I have not enabled UPnP.
-
That doesn't actually mean its not running - that is a wiget that can be edited to not show specific services.
-
@johnpoz
UPnP is not running:
-
@bchan hey dude, im interested in this as i saw exactly the same thing this morning, about 5 low ports opened by upnp and incoming UDP traffic however i now have no idea what opened them up. Do you have a PS4 on the network as its the only thing i can think that would do this?
-
@hulleyrob said in Had my pfSense been compromised?:
Do you have a PS4 on the network as its the only thing i can think that would do this?
I am running a small office and have no PS4 and have not enabled any uPnP.
-
@bchan ah ok i do have upnp enabled but have the same problem you are and cannot see after the even which computer opened up the ports just that there was a rule and its been deleted.
-
Which is exactly how upnp would work.. So it creates a rule to allow whatever was requested.. It then would delete that rule when request is removed.. So in the logs you would see just the rule ID..
Look with sockstat do you see miniupnpd running? Vs just the status, could be process that didn't shutdown or something.. Also look to see if the ports used are listening 1900, and I think maybe even 2189 or 5351 could be used.
here I enabled it for test
[2.4.4-RELEASE][admin@sg4860.local.lan]/root: sockstat | grep miniupnpd root miniupnpd 18015 4 tcp6 *:2189 *:* root miniupnpd 18015 5 dgram -> /var/run/logpriv root miniupnpd 18015 6 tcp4 *:2189 *:* root miniupnpd 18015 7 udp4 *:1900 *:* root miniupnpd 18015 8 udp6 *:1900 *:* root miniupnpd 18015 9 udp4 192.168.9.253:1920 *:* root miniupnpd 18015 10 udp6 *:44710 *:* root miniupnpd 18015 12 stream /var/run/php-fpm.socket root miniupnpd 18015 13 stream /var/run/php-fpm.socket root miniupnpd 18015 14 udp4 192.168.9.253:5351 *:* root miniupnpd 18015 16 udp6 *:5351 *:*
Then turned it off
[2.4.4-RELEASE][admin@sg4860.local.lan]/root: sockstat | grep miniupnpd [2.4.4-RELEASE][admin@sg4860.local.lan]/root:
-
@johnpoz is there any log or place i can look that would tell me what IP address requested the deleted rule to be added after the event?
My poroblem isnt that upnp is enabled as that is required for multiple PS4's to work on my network but that I cannot tell what device caused the open ports and requested the upnp rules once they are deleted.