Rich, et al,
Circling back on some older threads... I'm doing this because I've been
growing my cgnat environments and needing to remind myself of somethings,
etc...
If an attack is targeted at 1 ip address, you would think that if
would/could affect all the napt-44 (nat overloaded/pat'd) ip's that hide
behind it... but isn't that *IF* that traffic actually got through the nat
boundary and flowed to the intended target(s) ?
Unsolicited outside---->inside traffic I believe results in a deny of
traffic... and I'm seeing that the nat actually builds those flows as drop
flows....
I generated some traffic at a nat destination and I see all my traffic is
"Drop"... now I wonder if this is a fast path like in asic (pfe) hardware
being dropped... if so, it would seem that the nat boundary is yet a really
nice way to quickly drop unsolicited inbound traffic from perhaps bad
sources.
My source where I was generating traffic... Hollywood-ip (only works in the
movies) 256.256.191.133 (bad guy)
Nat destination where I sending traffic to... 256.256.130.4 (victim/target)
Now of course the resources/network outside the nat is bogged down, but the
inside nat domain seems to be unaffected in this case from what I can tell.
And again, I'm wondering if that "Drop" flow is lightweight/fast processing
for the ms-mpc-128g juniper gear ?
{master}
agould@960> show services sessions destination-prefix 256.256.130.4/32 |
grep 256.256.191.133 | refresh 1
---(refreshed at 2019-02-07 12:36:45 CST)---
---(refreshed at 2019-02-07 12:36:46 CST)---
---(refreshed at 2019-02-07 12:36:47 CST)---
---(refreshed at 2019-02-07 12:36:48 CST)---
---(refreshed at 2019-02-07 12:36:49 CST)---
---(refreshed at 2019-02-07 12:36:50 CST)---
---(refreshed at 2019-02-07 12:36:51 CST)---
---(refreshed at 2019-02-07 12:36:52 CST)---
TCP 256.256.191.133:54519 -> 256.256.130.4:443 Drop O
1
ICMP 256.256.191.133 -> 256.256.130.4 Drop O
1
---(refreshed at 2019-02-07 12:36:53 CST)---
TCP 256.256.191.133:54519 -> 256.256.130.4:443 Drop O
1
ICMP 256.256.191.133 -> 256.256.130.4 Drop O
1
---(refreshed at 2019-02-07 12:36:54 CST)---
TCP 256.256.191.133:54519 -> 256.256.130.4:443 Drop O
1
ICMP 256.256.191.133 -> 256.256.130.4 Drop O
1
---(refreshed at 2019-02-07 12:36:55 CST)---
TCP 256.256.191.133:54519 -> 256.256.130.4:443 Drop O
1
ICMP 256.256.191.133 -> 256.256.130.4 Drop O
1
---(refreshed at 2019-02-07 12:36:56 CST)---
---(refreshed at 2019-02-07 12:36:57 CST)---
---(refreshed at 2019-02-07 12:36:58 CST)---
UDP 256.256.191.133:12998 -> 256.256.130.4:80 Drop O
1
UDP 256.256.191.133:24444 -> 256.256.130.4:80 Drop O
1
---(refreshed at 2019-02-07 12:36:59 CST)---
UDP 256.256.191.133:12998 -> 256.256.130.4:80 Drop O
1
UDP 256.256.191.133:24444 -> 256.256.130.4:80 Drop O
1
---(refreshed at 2019-02-07 12:37:00 CST)---
UDP 256.256.191.133:12998 -> 256.256.130.4:80 Drop O
1
UDP 256.256.191.133:24444 -> 256.256.130.4:80 Drop O
1
---(refreshed at 2019-02-07 12:37:01 CST)---
UDP 256.256.191.133:12998 -> 256.256.130.4:80 Drop O
1
UDP 256.256.191.133:24444 -> 256.256.130.4:80 Drop O
1
- Aaron
-----Original Message-----
From: Compton, Rich A [mailto:rich.comp...@charter.com]
Sent: Thursday, April 6, 2017 3:49 PM
To: Aaron Gould; 'Ahmed Munaf'; 'Nanog@Nanog'
Subject: Re: CGNAT
Hi Aaron, thanks for the info. I¹m curious what you or others do about
DDoS attacks to CGNAT devices. It seems that a single attack could affect
the thousands of customers that use those devices. Also, do you have
issues detecting attacks vs. legitimate traffic when you have so much
traffic destined to a small group of IPs?
Rich Compton | Principal Eng | 314.596.2828
14810 Grasslands Dr, Englewood, CO 80112
