Am I being DoS attacked?
-
Then likely replies to outbound connections from something. Not a DoS attack in that case.
I would expect to see some outbound traffic at the time but perhaps you just disabled that on the graph?
-
@stephenw10 said in Am I being DoS attacked?:
Then likely replies to outbound connections from something. Not a DoS attack in that case.
I would expect to see some outbound traffic at the time but perhaps you just disabled that on the graph?
Unfortunately I did disable that. Now when I go back I see nothing at the same timestamp... :(
-
Not even a tiny increase? It only required minimal outbound traffic to request a much larger replies.
-
@stephenw10 said in Am I being DoS attacked?:
Not even a tiny increase? It only required minimal outbound traffic to request a much larger replies.
Think I managed to create a view that shows it, not so great with these graphs. It is based on the same data as the first, but custom and just showing the hour it happened;
Looks to me as if "delay average" dipped at the time, whatever that is? -
That's the ping time to the gateway so it's not like it caused increased WAN latency.
The outpass total value is what I'd be looking at there and it's too small to see in that graph.
-
@stephenw10 said in Am I being DoS attacked?:
That's the ping time to the gateway so it's not like it caused increased WAN latency.
The outpass total value is what I'd be looking at there and it's too small to see in that graph.
Agreed. Just so strange, and a little unsettling... Can I add some sort of logging that can be left running if it should happen again?
-
@furom This may help some?
-
Not really. That's pretty much what I'd expect to see for that level of downloading.
Basically it looks like something in your network downloaded something. Not especially unusual.
-
@stephenw10 That's at least something good then. The stuttering is a bit annoying, but happens rarely so if there is nothing else that ought to be done, I'll let it be then. Thanks
-
You'd only really expect it to cause issues with other traffic if it was filling the available WAN bandwidth. You might just not be seeing the actual peak there because of the averaging in the RRD graphs.
-
@stephenw10 That may be so of course. Where would I find the data graphs are generated from? Perhaps it will give some more details?
-
@furom Just to add my 2 cents here, proprietary streaming services (and we all know who we are talking about, for music at least) can sometimes create TCP tunnels that pass a UDP stream on the inside. And, in some cases, this could lead to dropped states (the firewall closes the connection because it considers it to be stale) because the keep-alive of the service is too low, coupled with a fast connection that has loaded the whole song or podcast longer than the keep-alive of the connection.
Maybe try changing the state policy of PfSense to conservative (System->Advanced->Firewall and NAT->Packet Processing->Firewall Optimization Options)?
-
@nightlyshark Thanks, that can be an option. But as is now it happens rarely so was more interested in finding the cause if possible. I will remember this if it gets worse though :)
-
@furom said in Am I being DoS attacked?:
Where would I find the data graphs are generated from? Perhaps it will give some more details?
You can find the rrd files the graphs are generated from in /var/db/rrd but there will not be any more data there than the graphs can display. The purpose of RRD is to retain older data at lesser resolution.
-
@stephenw10 Oh, thanks. Was for a bit hoping the opposite... :)
-
TL;DR, but maybe it's a bot port scanning for commonly used ports?
-
@provels said in Am I being DoS attacked?:
TL;DR, but maybe it's a bot port scanning for commonly used ports?
Well, It could be, but that intense it affects other traffic?
-
What is your WAN download bandwidth? If it's significantly larger than 2.7Mbps, which I imagine it is, then a short download like that really should affect other traffic. The other thing it might be is a large number of new connections or maybe a very large number of small packets.
It's almost certainly not some external scan/attack because that is pass traffic on WAN. So replies to something internal connecting out in this case.
Steve
-
@stephenw10 I think I have 250 down, so yes, should be plenty of bandwidth left. And the passin-traffic, I checked this while watching Youtube, and well, it comes really close. So don't think the 2.7Mb is what made things stutter... Almost as if someone pressed pause/play really fast (which I hope is not the case)
Once I sat on my remote, but don't think that was it this time... :D
