Weird Packets that cannot be blocked.
-
Hello,
I have pfsense running on a network that it is not connected to the internet.
And while everything seems to be working as it should (NAT, firewall rules, etc) i saw with Packet Capture a lot of packets leaving the WAN interface while they were not supposed to.
And they are a lot of packages per minute.
All off them have this form: X.X.X.X (Wan IP of PfSense) >202.12.27.33.500: UDP, length 360
And i also see the same traffic from a Domain Controller i have behind NAT, but without NATing the IP and showing the real one.
eg. 172.16.0.1 (Internal IP) >202.12.27.33.500: UDP, length 360
I tried to block UDP port 500 on pfSense and also add a deny outgoing rule on port 500 on my Domain Controller, but still the packets are passing the firewall.Any idea?
-
Not sure why you are seeing port 500, it's a DNS root server.
https://www.iana.org/domains/root/servers
mac-pro:~ andyk$ dig -x 202.12.27.33
; <<>> DiG 9.9.7-P3 <<>> -x 202.12.27.33
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6047
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;33.27.12.202.in-addr.arpa. IN PTR;; ANSWER SECTION:
33.27.12.202.in-addr.arpa. 86131 IN PTR M.ROOT-SERVERS.NET.;; AUTHORITY SECTION:
27.12.202.in-addr.arpa. 86131 IN NS ns.tokyo.wide.ad.jp.
27.12.202.in-addr.arpa. 86131 IN NS mango.itojun.org.
27.12.202.in-addr.arpa. 86131 IN NS ns-wide.wide.ad.jp.;; Query time: 43 msec
;; SERVER: xxxx:xxxx:xxxx:2::1#53(xxxx:xxxx:xxxx:2::1)
;; WHEN: Tue Oct 10 19:40:41 BST 2017
;; MSG SIZE rcvd: 171mac-pro:~ andyk$
-
Yeah 500 is not dns.. UDP 500 would normally be isakmp, why you would be sending it to a root server IP??
Your saying your also seeing it from a AD DC.. And its sending out your WAN without natting the rfc1918 to your public?
-
Could be those hosts are compromised and trying to DoS the root DNS server(s).
After adding a block rule, make sure to reset the states.
-
Maybe do a packet capture and set wireshark to decode UDP 500 as DNS.
-
If they were trying to dos, wouldn't they be sending malformed traffic to dns on 53? But sure anything is possible I guess.
As jimp mentioned if your going to put in block rules, you should clear the states after you put in rule.. Could you post up the rules your putting in place to block this traffic.. So we can see if they are correct.
-
If they were trying to dos, wouldn't they be sending malformed traffic to dns on 53? But sure anything is possible I guess.
As jimp mentioned if your going to put in block rules, you should clear the states after you put in rule.. Could you post up the rules your putting in place to block this traffic.. So we can see if they are correct.
Traffic is traffic, I don't expect much of anything that script kiddies and people that perform DoS attacks do to make sense. udp/500 is commonly allowed outbound, so it may slip by unnoticed. Though I would expect udp/500 to get dropped long before it reached the root server.
-
Very true ;) But since 500 a static port for nat on pfsense, prob couldn't be sending much traffic from clients behind anyway.
I have never looked into this… But what exactly happens if client 1 sends out isakmp and then client 2 and 3 all try doing it as well with port 500? Since its listed as a static port how does pfsense handle multiple clients all wanting to use that port?
Clearly off topic but the traffic on isakmp got me thinking of what would happen.. Guess I could always lab it an see ;)
-
Yeah 500 is not dns.. UDP 500 would normally be isakmp, why you would be sending it to a root server IP??
Your saying your also seeing it from a AD DC.. And its sending out your WAN without natting the rfc1918 to your public?
Exactly.
To give some more info about the network.
I have IPSEC on my network.
And i see tha same kind of traffic coming from both the Firewall itself and the DC.
UDP 500 to this root DNS ip.
This is why it is weird.
Even after disconnecting the DC, the Firewall kept sending these packets.
So, maybe the DC is compromised, but what about the pfSense?And here is a capture:
07:32:25.538773 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
07:32:25.741954 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
07:32:26.023376 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
07:32:26.226275 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
07:32:26.304458 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 360
07:32:28.538751 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
07:32:28.742394 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
07:32:29.038768 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
07:32:29.307334 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
07:32:30.320302 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
07:32:31.335691 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
07:32:31.538756 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
07:32:31.757434 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
07:32:32.038801 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
07:32:33.964202 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 360
07:32:34.335655 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
07:32:34.538719 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
07:32:34.757414 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
07:32:34.960600 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 360
07:32:35.038844 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
07:32:35.960667 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 360
07:32:37.335806 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
07:32:37.538648 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
07:32:37.757423 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380
07:32:38.054323 IP <wan address="">.500 > 202.12.27.33.500: UDP, length 380</wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan> -
And…it is fixed.
No clue how.
I just restarted the firewall. (I guess something i should have done first). ::)Thanks everybody for your time!