Should I be worried about this traffic?
Recently our office's internet seemed to be going out for about 2 minutes, every few days. I started poking around and found the firewall log kinda odd. I attached a (revised) screenshot of the denied traffic, and noticed most of those IPs being denied are from China. Any ideas as to what to do?
Thanks for any help.
onhel last edited by
Looks like pfSense is doing its job; they're all Blocked. If the fact that they are all coming from China worries you, give the Country Block package a try.
Yeah I suppose so. I cant do the country block package though, because we do have some legit connections coming from China. I guess what really worried me were the times, sometimes 6 attempts per second. Would maybe being overflown with (blocked) scans temporarily stop the internet from working in the office? Or should I look elsewhere for the problem?
lonevipr last edited by
I would imagine it's possible for your internet to go down. I mean that's what a DOS attack is. A flood of incoming reqs. So it is possible it could knock the connection offline for a few minutes with that many incoming connections.
I would suggest to do one of 2 things. Run snort (if you have the RAM available for use) or IPblocklist & make a your own custom blocklist file & put just the IPs of these bogus china connections in it. Therefore your not blocking all china connections (your legit ones), but are definitely blocking the spam/fake ones.
You can host your IPblocklist text file on an internal webserver & point IPblocklist to it.
Thanks for the suggestions. I will definitely look into the IPblocklist. I'll let you know how it goes.
Ok, so I have made my own custom list and am trying to block all these scanning IPs. It seems like a lot of IPs are trying to scan me. I have been adding more and more to the list for about an hour and a half now, and Im up to 30 blocked IPs - still adding more too. I don't see why there is such an interest in this network, or at least there appears to be. Any reasoning would maybe make my day better…
So maybe actively watching and blocking wasn't the greatest idea. I blocked an IP that apparently is a tool we use here. Not sure why it was scanning some ports, but oh well.
I switched over to some premade block lists (http://www.iblocklist.com/lists.php) , and I guess Ill wait to hear from people if they can't access something.
"trying to block all these scanning IPs"
Where are you seeing scanning – looks like traffic from the same source port a few destination ports. Not a scan, a scan would be connections to different ports, not the same ones.
Looks to me to be some sort of answer to something you requested?
I would suggest you sniff the traffic to see what it is before blocking it.
Johnpoz, thank you for your reply.
Well, the internet went down again today, twice, for about a minute each time. I have the firewall log of when it went down, but I can't seem to see anything relevant. Ill attach a screenshot of that. The internet went down at 13:25:20 - Here's what tells me that (system log):
Oct 18 13:25:40 root: IP-Blocklist was found not running Oct 18 13:25:38 check_reload_status: reloading filter Oct 18 13:25:33 root: IP-Blocklist was found not running Oct 18 13:25:32 check_reload_status: reloading filter Oct 18 13:25:28 apinger: alarm canceled: 75.x.x.201(75.x.x.201) *** down *** Oct 18 13:25:20 apinger: ALARM: 75.x.x.201(75.x.x.201) *** down ***
Not sure why "IP-Blocklist was found not running" either. I guess my true problem is that I dont know how to read the logs properly, leaving me guessing who I need to block. Im stumped, what would you guys make of the log, knowing the internet went down at 13:25:20?
Oct 18 16:09:57 WAN 184.108.40.206:17788 75.x.x.201:9388 UDP
Oct 18 16:09:49 WAN 220.127.116.11:17788 75.x.x.201:9388 UDP
Oct 18 16:09:43 WAN 18.104.22.168:17788 75.x.x.201:9388 UDP
FYI: This did not knock out my internet, I am just trying to get a grasp on log reading now.
Some quick googling shows its a China IP. What would cause that log to show up? Is there any legitimate reason for the 61.155 IP to try and reach 75.x.x.201? What's port 9388 used for? Is it possible someone here is looking up a chinese website, and its just normal traffic?
Also, in the previous attached image, at 13:25:48 the IP 22.214.171.124 is trying to do something to port 39586. That's a google IP address, I doubt that's trying to harm me, but what would it be doing for that to show up in my log?
Again its 3 packets that were blocked – this is not going to knock out anything.
You sure its not just your firewall blocking UDP packets that were in response to something requested by your network or maybe P2P?
I would really suggest you sniff the traffic your seeing before you go jumping to conclusions -- look at your state table to see if you have any clients that had made connections to those IPs for a start.
I see quite a bit of blocked UDP traffic on my firewall as well -- there is LOTS of noise on the net!
Without sniffing the traffic to see what the packets are don't jump to any conclusions about what the traffic is. Could be your clients running p2p? Which can be on lots of strange ports 17788 and 9388 are not listed ports for any sort of specific application that I can tell.
Again I would look to see if you have states open to those IPs from your clients, and for sure SNIFF the traffic to see what it is.
For example - I just took a quick capture, and noticed this blocked udp packet
126.96.36.199:42706 ---> 24.13.xx.xx:10704
Now look at the capture I have of that packet -- notice the d1:ad2:id20 - tells me its p2p DHT traffic!
yeah I run a p2p client, so your going to see LOTS of weird traffic - and sure your firewall will block stuff like this!
I would guess you got some people running p2p is all ;)
edit: I added a easier to read view of the data in that packet, I am no expert on the bittorrent protocol to be sure -- but it can generate quite a bit of traffic like this. Should those packets be allowed vs blocked (off to read up on the bit torrent protocol) -- I would think so. I should prob look into a way to do that ;) But once you join a p2p swarm, you can see traffic for days and days related to that joining.
Wow, thank you for your detailed response!
I will try and scan some traffic. I need to look into how to use wireshark effectively first though. Im sure google will help me with that though.
I installed snort as a package for now. Maybe that will work as well. Thanks again!
pfsense has built in capture – just capture and download, you can view the files with wireshark.
Thats the weird thing, I dont have that option. Im on the 1.2.3 release. You can see in my original post that there's no links to do so in my firewall traffic logs. Is there something I need to install, like a package or something?
I just found and installed the "Packet Capture Fix". However, it did not add anything it seems…
I have been on the 2.0 line for quite some time, but I thought that 1.2.3 had capture as well.
If not you might have some problems capturing traffic on your wan interface. So if you shell to your box you don't have tcpdump?
cmb last edited by
You're chasing and worrying about something that isn't in any way related, looks like you're just losing your Internet connection briefly on occasion, and the little bit of blocked Internet noise you have in the logs isn't related.
Packet capture is under Diagnostics>Packet Capture but that's not likely to be of any help.
Keep constant pings going to a variety of things, your WAN IP, your WAN's gateway, and something on the Internet, and see what succeeds and what fails when it drops.
I agree he is worried about noise, but actually looking at the traffic will clear his mind that he is under some sort of attack and that the traffic is just noise - I would guess p2p myself from the ports and being and upd most likely dht type traffic.
Once he has cleared his mind that its just that and not some attack quite possible its just his isp having issue for his loss of internet.
Look at your quality graph.. how does it look? This should show you possible loss of of internet when your gateway does not answer pings.
Ok so its been awhile… other pressing issues and whatnot. So I enabled SSHing in and started playing around with tcpdump. Im still trying to figure out how to use it correctly though. Any tips?
EDIT: WOW, I did not see the 2nd page on this thread. Im looking at the quality graph but am unsure what to look at. Ill stare at it some more though!
Johnpoz was right, I am able to get a capture file from diagnostics->packet. So I guess Ill disable SSH and forget about tcpdump for now.
I loaded that .cap file in wireshark but dont really know what to look for. I guess my next step is to contact my ISP with a list of times our internet went out and see if they can see it on their end.
I already went over what to look for in the packet capture in post number #10
Did you see d1:ad2:id20 in the payload?
If so then its just P2P noise!!! You can filter it out if you want from the log so you don't get all freaked out about such NOISE
I would be happy to look at the packet capture you took if you want - just PM it to me. or Post it.
To filter just create a layer 7 container for bittorrent, then a wan firewall rule on to block that layer 7 and not log it. Now your P2P noise will be gone and you can stop freaking out about NOISE ;)
After your posts I decided I didn't need to see all that noise either - so that is what I did.
Like I said the internet is FULL OF NOISE!!! Yes the default block that blocks all unwanted traffic is going to log that noise. So you can either create the block all rule yourself and not log it, or if you want you can just filter out what is clearly P2P traffic your seeing for example d1:ad2:id20 in the payload via a layer7 rule and not log it. So this way you will just see non p2p stuff that is blocked ;) And should be less information that your seeing.
As to your quality RRD graph – what is it you do not understand? It is showing you the response times to your gateway, if if you lost connectivity to your ISP gateway it would show in this graph.. Its pretty straight forward -- not sure what else to say.