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.

jimp

Do you have UPnP enabled? Do you have it set to use WAN2, and to log connections?

That's the most likely explanation.

johnpoz

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.

jimp

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.

bchan

@jimp said in Had my pfSense been compromised?:

Do you have UPnP enabled?

No I have not enabled UPnP.

johnpoz

That doesn't actually mean its not running - that is a wiget that can be edited to not show specific services.

bchan

@johnpoz
UPnP is not running:

hulleyrob

@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?

bchan

@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.

hulleyrob

@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.

johnpoz

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: