yes... which leads back to a full circle on another aspect of
ISP/NSP/WISP systems...
Centralized Syslog
with / easy access to retrieve info..
Lots of desired functionality, Monitoring, DDOS, logging etc etc
would lead back to a centralized logging system.
:)
Faisal Imtiaz
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232 <tel:%28305%29%20663-5518>
Help-desk: (305)663-5518 <tel:%28305%29%20663-5518> Option 2 or
Email: [email protected] <mailto:[email protected]>
------------------------------------------------------------------------
*From: *[email protected] <mailto:[email protected]>
*To: *[email protected] <mailto:[email protected]>
*Sent: *Wednesday, December 28, 2016 11:26:39 AM
*Subject: *Re: [AFMUG] Mikrotik - Carrier Grade NAT methods
Yeah, DHCP lease info is the thing to save.
*From:* Adam Moffett
*Sent:* Wednesday, December 28, 2016 9:21 AM
*To:* [email protected]
*Subject:* Re: [AFMUG] Mikrotik - Carrier Grade NAT methods
I think Eric is saying if you're going to the effort of
logging NAT translations then you also should log DHCP
assignments. Which is true.
------ Original Message ------
From: "Dennis Burgess" <[email protected]>
To: "[email protected] <mailto:[email protected]>" <[email protected]>
Sent: 12/28/2016 5:50:22 AM
Subject: Re: [AFMUG] Mikrotik - Carrier Grade NAT methods
But this is not required.. Something of course, you can do.
Dennis Burgess
www.linktechs.net <http://www.linktechs.net/> –
314-735-0270 x103 <tel:%28314%29%20735-0270> –
[email protected]
*From:*Af [mailto:[email protected]] *On Behalf Of
*Eric Kuhnke
*Sent:* Tuesday, December 27, 2016 8:01 PM
*To:* [email protected]
*Subject:* Re: [AFMUG] Mikrotik - Carrier Grade NAT methods
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
<[email protected]> wrote:
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
<[email protected]> wrote:
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
<[email protected]> 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
<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
