Hi Justin,
Good point, not a DDOS at all, just a DOS.
Yes, the packets were dropped, I guess the only potential protection is
upstream.
If i do shorewall-drop (ip) , the packets will still hit the interface,
but does it still appear in the logs ? Actually, looks like they are
dropped silently ?
Not going to help for UDP, but it would stop TCP replies if it was a TCP
flood ?
Thanks for you input Justin,
Best Regards,
Richard
On 20/09/2018 9:10 AM, Justin Pryzby wrote:
On Thu, Sep 20, 2018 at 08:52:20AM +1000, Richard wrote:
My child was playing fortnite last night when another kid in the lobby
threatened to DDOS him,
It doesn't appear to be "distributed", right ?
SRC= 98.139.130.248
SRC= 98.139.130.248
SRC= 98.139.130.248
SRC= 98.139.130.248
Is there a mechanism in shorewall to prevent this particular attack ?
My first thought was rate limiting, but perhaps there are other security
measures available ?
The packets were dropped, right ? So there's nothing to limit, unless you can
cause the packets to be dropped further upstream (router/ISP).
But note this:
http://shorewall.org/manpages/shorewall-tcinterfaces.html
|IN-BANDWIDTH (in_bandwidth) -
{-|bandwidth[:burst]|~bandwidth[:interval:decay_interval]}
|
| The incoming bandwidth of that interface. Please note that you are not
able to do traffic shaping on incoming traffic, as the traffic is already
received before you could do so. But this allows you to define the maximum
traffic allowed for this interface in total, if the rate is exceeded, the
packets are dropped. You want this mainly if you have a DSL or Cable connection
to avoid queuing at your providers side.
|
| If you don't want any traffic to be dropped, set this to a value to zero
in which case Shorewall will not create an ingress qdisc.Must be set to zero if
the REDIRECTED INTERFACES column is non-empty.
which I take to mean that if you have an interface for which the "total
bandwidth" (in+out) is capped by the ISP, you can define that to avoid keeping
an increasing queue of stale, outgoing packets, which are useless and harmfully
keeping more recently sent packets from being transmitted.
Justin
--
Best Regards,
Richard Hatherly
Ritech Computing Services
0411 459 507
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
