Greylog2 if you have some expertise around pulling information back out of it - Splunk is great too and more polished with plugins and support available ….
We are probably migrating from Splunk to Greglog2 this year … need something more scalable (as compared to our current Splunk license tier and upgrading it again). > On Dec 31, 2016, at 9:03 PM, David Milholen <[email protected]> wrote: > > +1000 > We do this with no issues and use LogAnalyzer as the mysql front-end for all > the logs. It has lots of ease of use filters to quickly get what u need. > It help me figure out what I needed to for fail2ban on our dns servers. > > > On 12/28/2016 12:40 PM, Josh Baird wrote: >> The simplest thing to do is to just run rsyslogd on Linux host somewhere on >> your network and push all of your device's syslog to that host. It's >> trivial to configure rsyslogd to write each device's logs to a separate >> path/file, configure log rotation, etc. >> >> If you need something beyond that (with >> search/matching/alerting/visualization capabilities) you could start looking >> at Graylog2, an ELK stack (with Kibana) or Splunk. >> >> On Wed, Dec 28, 2016 at 1:36 PM, Adam Moffett <[email protected] >> <mailto:[email protected]>> wrote: >> Actually I'd love suggestions on that front too. >> I've looked at Splunk, Graylog, and Zabbix all pretty recently. None of >> them really excited me to be honest. >> >> Splunk had the interesting ability to automatically indicate messages that >> were statistically normal....it just seemed like there was a lot going on >> and a lot features I would never use. >> >> I don't really know what my criteria are for the perfect log >> collector/analyzer, I just don't think I've seen it yet :) >> >> >> ------ Original Message ------ >> From: "Faisal Imtiaz" <[email protected] >> <mailto:[email protected]>> >> To: [email protected] <mailto:[email protected]> >> Sent: 12/28/2016 12:28:20 PM >> Subject: Re: [AFMUG] Mikrotik - Carrier Grade NAT methods >> >>> 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 >>> >>> >>> >>> >> > > -- > <Davidmvcf.jpg>
