Carriers and hardware with better Netflow support would make this so much 
easier. 




----- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 




----- Original Message -----

From: "George Skorup" <geo...@cbcast.com> 
To: af@afmug.com 
Sent: Tuesday, December 27, 2016 8:40:16 PM 
Subject: Re: [AFMUG] Mikrotik - Carrier Grade NAT methods 

Yeah.. "Who/what was using x.x.x.x on Dec. 21st?" How about a source port # 
with that? "No port." OK, sorry, can't help you. Gimme a port and I'll run a 
netflow report. The DMCA turds do this: x.x.x.x:49152 was sharing movie X. 
Those are easy. 

I have also recently started dedicating a public IP per L2 segment and NATing 
ports 3074-3076 to it. Works great for quickly shutting down a DDoS by sending 
that specific IP (instead of a NAT pool address) to our RTBH peers. The Xboxies 
don't work no more, but I don't give a shit. Cry me a river. If the kids (and 
adult kids) want to talk shit and get DDoS'd, fuck em. 


On 12/27/2016 8:17 PM, Mathew Howard wrote: 




Keeping logs of who is on what IP at any given time is a simple enough matter, 
but if there are 50 customers on private IPs NAT'd to a single public IP, and 
all the subpoena gives you is the public IP, I'm not sure how that helps. 

I'm hoping we'll have IPv6 working on all our customers by the time we run out 
of IPv4 address, and we can just run dual stack with CGNAT... I'm thinking the 
combination of having port blocks assigned to specific private IPs and IPv6 
would cover the majority of these cases. 



On Tue, Dec 27, 2016 at 8:00 PM, Eric Kuhnke < eric.kuh...@gmail.com > wrote: 

<blockquote>

Assuming you have a NAT and dhcp pools of IPs defined inside the NAT, unique 
pool per POP, if you do not have log files from your dhcp daemon, you are 
taking a terrible risk... Log files are small relative to the cost of disk 
space. In setups I have built in the past with the ISC dhcpd we kept logs going 
back 24 months for which CPE at which MAC address had which IP address (whether 
internal or an ARIN IP) at any given point in time, including the 
lease/assignment handshake. 






On Tue, Dec 27, 2016 at 5:58 PM, Mathew Howard < mhoward...@gmail.com > wrote: 

<blockquote>


The problem I see with that though, is the subpoenas we've gotten are generally 
just an IP address, and a time period... if this is coming from something like, 
say, a facebook post, is there typically going to be any log of that sort of 
thing? 


Assigning port blocks would work fine for things like bittorrent DMCA takedown 
notices, where they give you port information, but I'm not sure how you would 
use it to track down a specific customer when all they give you is the IP 
address... 





On Tue, Dec 27, 2016 at 6:51 PM, Josh Reynolds < j...@kyneticwifi.com > wrote: 



<blockquote>
If you assign a port block per customer (PBA NAT in Juniper), you 
don't really need to log anything... do you? 



On Tue, Dec 27, 2016 at 3:45 PM, Adam Moffett < dmmoff...@gmail.com > wrote: 
> A recent thread about a subpoena made me wonder. Historically this hasn't 
> been an issue for me because I've had access to enough public IP's...but it 
> might become an issue soon. 
> 
> Has anybody set up CGN with appropriate logging on Mikrotik? 
> I'm thinking you would have to log every set of src-ip, dst-ip, src-port, 
> and dst-port for each connection that a customer opens. Does simply 
> checking the "log" checkbox on the srcnat rule generate enough data or is 
> there more to it? 
> 
> Has anybody tried the method on the wiki 
> ( 
> http://wiki.mikrotik.com/wiki/Manual:IP/Firewall/NAT#Carrier-Grade_NAT_.28CGNAT.29_or_NAT444
>  ) 
> where you assign a range of port numbers to each private IP? The idea is 
> you don't have to log everything at that point because you know that a 
> connection from port x corresponds to private ip y. Then you just need to 
> keep track of who has which private IP. It seems like this would have a 
> side effect of limiting the number of simultaneous connections a single 
> customer could open....maybe not a bad thing. 
> 
> Thanks, 
> Adam 




</blockquote>


</blockquote>


</blockquote>


Reply via email to