Question about 3 types of packets SuSEfirewall2 drops

Silicon_Penguin67 · March 25, 2014, 9:51pm

Howdy all.

I have questions about 3 types of packets my firewall is dropping. They’re all related to DNS, I guess. My first assumption is always “I must have mis-configured something”.

The first:

2014-03-25T15:18:35.761420-05:00 siliconpenguin kernel: [72775.946679] SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC= SRC=71.86.xxx.xxx DST=224.0.0.251 -snip- DF PROTO=UDP SPT=5353 DPT=5353 LEN=41

So, I believe this is an mDNS broadcast packet. What might be broadcasting this packet? Do I have something mis-configured? Could it be something on my internal network requesting this? BTW, I find it weird that IN=eth0. That’s the network card facing the internet. The SRC=71.86.xxx.xxx is eth0. I log about 10 - 20 of these a day.

Ok, next:

2014-03-25T14:48:45.952426-05:00 siliconpenguin kernel: [70986.139003] SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:1a:blahblah SRC=24.196.64.46 DST=71.86.xxx.xxx --snip-- PROTO=UDP SPT=53 DPT=2050 LEN=96

The SRC=24.196.64.46 is a DNS server from my ISP, so this seems legit. But why are they sending me on average 50 - 100 of these a day. I’ve only seen port 2050 used for two things: Avaya EMB Config Port and a window trojan. That doesn’t mean it couldn’t be for some other legit purpose.

Moving on. This one is a little different. I see whats happening, just not the how or why:

2014-03-25T10:00:27.242024-05:00 siliconpenguin kernel: [53687.428606] SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:1a:blahblah SRC=60.166.27.50 DST=71.86.xxx.xxx --snip-- PROTO=ICMP TYPE=3 CODE=3 [SRC=71.86.xxx.xxx DST=60.166.27.50--snip-- PROTO=UDP SPT=15777 DPT=53 LEN=50 ]

So this looks like someone, from South Africa, is pinging my box. The part that confuses me is DPT=53?? Again with the DNS port? That wouldn’t be normal for a ping request, right?

Thanks in advance for any tips or help! If you could point me in the right direction I’d really appreciate it.
Please let me know if you need anything else…
Cheers, Terry.

Silicon_Penguin67 · March 25, 2014, 10:04pm

Also, I am not running a DNS server!

Silicon_Penguin67 · March 25, 2014, 10:30pm

One more thing. After scanning my logs a bit more thoroughly, there is a variation to the second type of dropped packet:

 --snip-- SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:1a:blahblah SRC=79.98.50.22 DST=71.86.xxx.xxx --snip-- PROTO=UDP SPT=53 DPT=15264 LEN=124

So far today I’ve received 73 packets of variety two(from my first post). 24 of them don’t appear to be from my ISP, like this one from Belarus. And, they all go to DPT=15264?

Cheers,
Terry.

tsu2 · March 26, 2014, 12:11am

First,
It might be of moderate interest to identify the logs you’re getting your entries.

But,
What you really need to do is feed your logs into a packet analyzer. Oftentimes an app like Wireshark can help you identify the relevant parts of the log entry and even color code the protocols automatically so you can better understand patterns. If you become more advanced and want to do some really powerful slice and dice of your data you can apply some Unstructured Big Data Analysis like the tool I’ve blogged how to setup on openSUSE
http://en.opensuse.org/User:Tsu2/elasticsearch_1.0

Wireshark might verify what I suspect, the packets are merely queries on the network related to cisco routing
http://en.wikipedia.org/wiki/Dynamic_Packet_Transport

I’m not sure where you got an idea the traffic might be related to DNS aside that you might already know that DNS is provided by that machine…
A good exercise is to actually capture some DNS traffic with wireshark and compare to your suspect packets.

TSU

Silicon_Penguin67 · March 26, 2014, 2:03am

TSU, thanks for the reply. Your right, I should have mentioned that I was talking about the firewall log. I didn’t because my post was titled: “Question about 3 types of packets SuSEfirewall2 drops”, which kinda mentions SuSEfirewall2.
I figured it was apparent, sorry.

TSU said:

I’m not sure where you got an idea the traffic might be related to DNS aside that you might already know that DNS is provided by that machine…

I actually know that DNS is NOT provided by my machine. I can query any of the ip addresses involved with whois, and verify which are my ISP.

I get the idea that the traffic is related to DNS because:

According to rfc 6767, IP address 224.0.0.251:5353 is used for mDNS, or Multicast DNS. See http://tools.ietf.org/html/rfc6762#section-3
Port 53 is the assigned port for DNS. See http://tools.ietf.org/html/rfc5452
And this is an ambiguous connection(sic), packets with a source port of 53(DNS), and a destination port of 2050 are used for the Avaya EMB Config Port Service. Or the PWSteal.Ldpinch backdoor trojan. I think that’s just on windows though.

TSU said:

A good exercise is to actually capture some DNS traffic with wireshark and compare to your suspect packets.

Now that’s not a bad idea.
I apologize if I seem to be a bit snarky. I do appreciate any and all input.

I’ve been writing a script that parses the log file, the firewall log, and querys the source ip address to compile a list of what countries are attempting to login to my machine via telnet, or ssh, or whatever. So far China’s winning. I’ve noticed an increase in DNS related dropped packets over the last few weeks. That’s why I was wondering if I may have mis-confugured something.

Thanks and cheers,
Terry.

tsu2 · March 26, 2014, 3:55pm

After a little bit of searching, it appears that port 5353 may be used by a few different services, but all for some kind of multi-cast functionality (on *NIX, probably bonjour)

Although there are plenty of articles on the Internet that briefly describe multi-cast and port 5353, I might suggest this article where the author configures his home network for using the application Draw (which apparently uses multi-cast). The article describes his procedure for creating iptables rules and has several Wireshark screenshots.
https://community.jboss.org/wiki/JGroupsWiresharkExample

So, “dpt” in this case really does merely denote the port and not a protocol.

TSU

robin_listas · March 26, 2014, 6:53pm

On 2014-03-26 02:06, silicon penguin67 wrote:
>
> TSU, thanks for the reply. Your right, I should have mentioned that I
> was talking about the firewall log. I didn’t because my post was
> titled: “Question about 3 types of packets SuSEfirewall2 drops”, which
> kinda mentions SuSEfirewall2.

It was obvious to me they were susefirewal2 logs entries, I recognized
the format

> I actually know that DNS is NOT provided by my machine. I can query any
> of the ip addresses involved with whois, and verify which are my ISP.

You can try a dig against yourself and find out for sure. The ports used
indicate that the traffic is related to DNS, yes, but it does not mean
you run a dns server. They are incoming packets: that something outside
thinks you may have a dns server does not mean you have

The first one, on port 5353, is listed as:

mdns 5353/tcp # Multicast DNS [Stuart_Cheshire_2]

What is that machine, 71.86.xxx.xxx, your ISP or somebody else? That
would give a clue. And of course, capturing the actual package would be
more informative.

You have some info about mdns on the wikipedia. Linux uses it. You can
open the firewall for it or close it and forget.

Wait…

Is the 71.86.xxx.xxx, your IP range? Is the 71.86.xxx.xxx above another
machine on your range? And you are using Internet addresses? Then that
packet is absolutely normal. Atypical, but normal.

The second entry comes from port 53, so yes, that should be a packet
from the DNS service. It could be an answer packet that comes way out of
sequence :-?

The third one is, perhaps, someone testing to find out if you have a DNS
server :-?

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

Silicon_Penguin67 · March 26, 2014, 9:01pm

Thanks for getting back. A description of my network:

Cable modem: faces the net and my server.

My Server: eth0 faces the cable modem and has the ip address 71.86.xxx.xxx. eth1 faces the internal network. Actually, it connects directly with a wired/wireless router.

The internal router: A handful of PCs, notebooks, cell phones, and other devices connect to the server via the router.

All of the devices on the internal network get their ip addresses from the router via dhcp. I’m thinking that the mDNS packets are coming from something on the internal network. Should I open a port for them? hmm…

The really confusing thing for me at this point is the type 2 packets from my original post:


--snip-- SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:1a:blahblah SRC=24.196.64.46 DST=71.86.xxx.xxx --snip-- PROTO=UDP SPT=53 DPT=2050 LEN=96
 --snip-- SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:1a:blahblah SRC=79.98.50.22   DST=71.86.xxx.xxx --snip-- PROTO=UDP SPT=53 DPT=15264 LEN=124

The first one, from 24.196.64.46, is from my isp. The second appears to be someone scanning for a DNS server.
Now, should I open this port for my isp? If I do, what about these packets from other sources? Wait a minute. Nothing on my network seems to be having a problem resolving ip addresses. I guess maybe saving a days worth of packets using wireshark might give me insight as to weather or not the packets coming from my isp are actually responses to requests from my network or not.

So I’ve examined logs as far back as last September and the firewall has always dropped at least some packets from my isp. The weird thing is it was only recently that the packets from my isp started always going to port 2050. They used to go to a wide, almost random array of ports on my machine, which is what you’d expect according to the DNS specification. So why did they start only going to port 2050? Or, why are the only ones being dropped by my firewall going to port 2050?

I guess I’m going to investigate this further on my own. If anyone is interested, I’ll post whatever I find out on this thread.

tsu2 · March 27, 2014, 12:19am

According to the posts I skimmed…

Various services might use port 5353. All likely related to multicast. Not necessarily mDNS.

Whether to close the port really depends on knowing what you’re running internally.
If you’re not running any multicast application, shutting down the port should be safe.
If you run into some issue, the port can always be re-opened again.

TSU

Silicon_Penguin67 · April 1, 2014, 6:08am

So I’m in the middle of switching from phpWebsite to Drupal. I have all incoming ports closed. I still get a crazy high number of DNS packets dropped by the firewall. Examining them shows most are packets coming in out of sequence - really late. All the rest, just under half, are probes to see if I have DNS running. I guess the high number of dropped packets from my ISP are responses to device requests from my internal network. Unless I setup a packet sniffer inside my network I’ll never know which devices these dropped packets were for. I don’t think it matters, no one was having a hard time getting anywhere… Alright then, Cheers,
Terry.