Speaker 1: Is keeping your network secure feeling like, uh, just this
Speaker 1: constant battle against a flood of data.
Speaker 2: It really can be overwhelming.
Speaker 1: Yeah, and are you confident you've plugged every single hole
Speaker 1: against attacks? Is your sound system, you know, really seeing
Speaker 1: what it needs to see?
Speaker 3: Or maybe you're just starting out right and wondering where
Speaker 3: do I even begin with intrusion detection exactly?
Speaker 1: If any of that sounds familiar, well, you're definitely in
Speaker 1: the right place today. Our source material kicks off with
Speaker 1: those exact questions.
Speaker 3: Finding those critical signals, the important bits amidst all that
Speaker 3: network noise.
Speaker 2: That's the core challenge.
Speaker 1: Really absolutely, and that's what we do here on the
Speaker 1: Deep Dive. We take dense information like this fantastic guide
Speaker 1: we're looking at and try to pull out the key
Speaker 1: insights for you, you know, those aha moments.
Speaker 3: So our mission today is pretty focused. We want to
Speaker 3: understand how you can build a robust intrusion detection system
Speaker 3: and IDs and also a SIME environment, and.
Speaker 1: Crucially doing it with open source tools that are freely available.
Speaker 1: That's right.
Speaker 3: Our guide for this is Richard Medlins A Network Defender's
Speaker 3: Guide to Threat Detection using zeke Elastic Search log Stash, Cubana,
Speaker 3: tor and more.
Speaker 1: Quite a title promises a lot, and we're hoping to
Speaker 1: make that journey a bit smoother.
Speaker 3: What's interesting is a guide itself points out a big hurdle.
Speaker 3: You can find info on installing these tools one by one, sure,
Speaker 3: but getting them all configured to work together effectively clear
Speaker 3: up to date guides are surprisingly hard to come by.
Speaker 1: Okay, so let's unpack the toolkit we've got. Zeke used
Speaker 1: to be called BRO. Some might remember that name. The
Speaker 1: elastic search, Logstash, and Cubana. That's the ELK.
Speaker 3: Stack, the classic ELK stack.
Speaker 1: Yeah, finally, tour the Nanimity network. The source says getting
Speaker 1: these to play nice is tricky, so let's try and
Speaker 1: clear that path.
Speaker 3: Okay, let's start with the foundation Zeke. Our guide rightly
Speaker 3: calls it a cornerstone for a solid IDs.
Speaker 1: So Zeke formerly BRO maybe a nod to Orwell's nineteen
Speaker 1: eighty four seems kind of fitting for network monitoring. Maybe
Speaker 1: a bit ominous, huh?
Speaker 3: Maybe it's open source Network analysis software functions as a
Speaker 3: network intrusion detection system, and an IDs basically gives you
Speaker 3: a live view of network happenings.
Speaker 1: What makes it special though. It's not just basic pattern matching,
Speaker 1: is it.
Speaker 3: No, that's the key thing. It's smarter. It analyzes live traffic, yes,
Speaker 3: but also files moving across the network, even old recorded
Speaker 3: traffic and pccapy files, and it generates these neutral events
Speaker 3: based not just on known attack signatures, but also on
Speaker 3: network behavior that seems unusual.
Speaker 1: Right, So it's like noticing someone acting suspiciously near the building,
Speaker 1: not just spotting a crowbar.
Speaker 2: Exactly like that.
Speaker 3: Yeah, and it has built in analyzers for common protocols, HTTP, FTPS,
Speaker 3: mtp DNS, the usual suspects.
Speaker 1: And you can add more if needed.
Speaker 2: You can.
Speaker 3: Plus, it integrates with other tools like snort and crucially
Speaker 3: for US today, with elastic search.
Speaker 1: The guide mentioned some basic dependencies libcap for packet capture,
Speaker 1: open SSL for crypto, usual build tools like make c
Speaker 1: plus plus RAG.
Speaker 3: Yeah, the standard stuff for building from sores. But it
Speaker 3: quickly gets practical focusing on prepping Aubuntu for good packet capture.
Speaker 1: Right, you need to see the traffic clearly first, So
Speaker 1: step one, according to the guide, disable network manager. Why
Speaker 1: turn that off?
Speaker 3: Well, think of network manager as like the automatic pilot
Speaker 3: for your network connection.
Speaker 2: It tries to be helpful manage things.
Speaker 1: Which is usually good.
Speaker 3: Usually yeah, But when we're doing passive sniffing just listening in,
Speaker 3: it's active management can actually interfere, maybe drop packets or
Speaker 3: change how we see them.
Speaker 2: So for a.
Speaker 3: Dedicated sensor, you want it off. The guide gives the
Speaker 3: system trick to ural commands.
Speaker 1: Okay, that makes sense, less interference. Next step disabling NIC
Speaker 1: offloading functions sounds technical? What's the risk here?
Speaker 3: Modern network cards and icees they do tricks and hardware
Speaker 3: to speed things up right, take some load off the
Speaker 3: main CPU.
Speaker 1: Like handling checksums or segmenting large data packets.
Speaker 3: Exactly, things like TCP segmentation offloading TSO, Generic segmentation offloading GSO,
Speaker 3: Large receive offloading LRO all designed for performance, but they
Speaker 3: can bundle packets together or change packet timing in ways
Speaker 3: that distort the picture for our analysis tool. For ZEKE,
Speaker 3: you might even see packet sizes reported that are technically impossible.
Speaker 1: Ah, so we need the raw, unaltered stream. We need
Speaker 1: to turn those hardware shortcuts off on our analysis machine precisely.
Speaker 3: The guide shows using the f tool command with a
Speaker 3: bunch of flags rx tx, TSO, UPHO, GSO, grow l, row,
Speaker 3: et cetera, setting them all.
Speaker 1: To off, and the guide stresses you probably need to
Speaker 1: run this f tool command every time you start zeke.
Speaker 3: Yeah, that's a key point because those settings might not
Speaker 3: persist across reboots. You use f toolpinae to check their off.
Speaker 3: Some might say they can't be changed, but you verify
Speaker 3: the important ones are off.
Speaker 1: Okay, Then it mentions ensuring the DNS network service is
Speaker 1: running but not really changing its can fig Yeah. Then
Speaker 1: the big one, promiscuous mode sounds sneaky.
Speaker 3: Hu Well, Normally your network card only listens to traffic
Speaker 3: specifically addressed to it, like a polite receptionist only taking
Speaker 3: calls for their extension. Right, Promiscuous mode tells the card
Speaker 3: listen to everything, all traffic hitting the wire on that
Speaker 3: network segment.
Speaker 1: Doesn't matter who it's for, which is absolutely essential for
Speaker 1: an IDs. Otherwise you'd miss most of the conversations.
Speaker 3: Totally essential. If it's not promiscuous, it only sees traffic
Speaker 3: to the analysis box itself, useless for monitoring others.
Speaker 1: The guide shows if canfig interface promises to turn it
Speaker 1: on and ip A show interface rep I promised to
Speaker 1: check handy check YEP.
Speaker 3: Then it lists dependencies core ones we mentioned, but also
Speaker 3: optional stuff like GUOIP support.
Speaker 1: Ah geolocation so zeke can tell you where traffic is
Speaker 1: coming from or going to geographically based on IP address exactly.
Speaker 3: Using the limex mindb library and the free geolite two
Speaker 3: database super useful for spotting, say, unexpected international connections. Has
Speaker 3: that set up, The guide walks through app to get
Speaker 3: installed lib max mindyb dev, then using curl to download
Speaker 3: the geolite two city database, putting it in our share
Speaker 3: gip and it wisely says check for updated download links.
Speaker 1: Things change good tip Okay, next up. Pfriing sounds fast.
Speaker 2: It is.
Speaker 3: It's all about boosting packet capture speed, getting higher data
Speaker 3: rates than standard Linux methods.
Speaker 1: How does it work?
Speaker 3: Basically, it uses a Linux kernel mechanism called NAPI new Api. Essentially,
Speaker 3: it creates a more direct, efficient path for packets from
Speaker 3: the NIC into memory buffers that Z can access quickly
Speaker 3: reduces CPU overhead. Think of it like an express lane
Speaker 3: for packets.
Speaker 1: Gotcha, and installation looks like compiling from source again.
Speaker 3: Yep, get the code from GitHub, compile it with Make
Speaker 3: install the kunnel module the guide puts it in opt
Speaker 3: which is common for optional software.
Speaker 1: So the steps are installed. Build tools like bison flex right.
Speaker 3: Get, clone the pfring rebo cd into the kernel directory,
Speaker 3: Make Pseudo, make install, then Pseudo in smithmad to load
Speaker 3: the kernel module. It even covers building userspace libraries and
Speaker 3: TCP dump with pfr ing support.
Speaker 1: Okay, lots of prep work. But finally installing zke itself.
Speaker 2: Yes, clone the.
Speaker 3: Z cre go from GitHub, use the recursive flag that's important.
Speaker 3: Gets all the submodules right. Then the classic dot configure,
Speaker 3: make make install. The configure step is key. You tell
Speaker 3: it where PFI an G is, where guyp is. The
Speaker 3: guys suggests installing.
Speaker 1: To opsec compilation can take a while, I bet can do.
Speaker 3: Then a reboot is needed. Update your system's path so
Speaker 3: you can just type z commands easily.
Speaker 2: Almost there.
Speaker 1: Okay, installed. How do we tell zeke what to monitor?
Speaker 1: Basic config that's next.
Speaker 3: Two main files and ops can secut dot no dot
Speaker 3: cfg and networks dot cfg.
Speaker 1: No. Dot cfg is four.
Speaker 3: Defining your zke setup for a simple single sensor. The
Speaker 3: main thing is telling it which network interface to listen
Speaker 3: on the one we set to permiscuous mode earlier.
Speaker 1: And networks dot cfg.
Speaker 3: That's where you define your local IP address ranges, you know,
Speaker 3: using cid R notation like one ninety two point one
Speaker 3: sixty eight point one point zero two four or ten
Speaker 3: point zero point zero zero point zero eight. This helps
Speaker 3: zeke know what's internal versus external traffic.
Speaker 1: Makes sense. It also mentioned local dot Zeke.
Speaker 2: Yeah, that's like.
Speaker 3: The main control panel for enabling or disabling different Zke
Speaker 3: analysis scripts.
Speaker 2: You load the scripts you.
Speaker 1: Want to run there installed configured basics. Time to fire
Speaker 1: it up right.
Speaker 3: First, you need to give the zeke binari's permission to
Speaker 3: actually capture packets using the set cap command. It's a
Speaker 3: security thing, okay. Then you use zke toil the command
Speaker 3: line controller first time ever. You run zeke toil install.
Speaker 3: After that to start it with your config you use
Speaker 3: ziketil deploy and check if it's running zeke til status
Speaker 3: and you can watch the logs live like the connection
Speaker 3: log with tail opt sk logs, current con dot log.
Speaker 3: See the traffic rolling in phew.
Speaker 1: Okay, solid foundation with zeke running. Now the guide switches
Speaker 1: gears to tour. Why bring an anonymity tool into an
Speaker 1: intrusion detection discussion seems backwards.
Speaker 3: That's a great question, and the guide tackles it directly,
Speaker 3: understanding tour, how it works, what its traffic looks like.
Speaker 3: It's actually idle for defense how so, well, partly it's
Speaker 3: no your enemy right, understand the tool attackers might use,
Speaker 3: but more practically, seeing tour traffic inside a typical corporate network,
Speaker 3: that's usually a big red flag.
Speaker 1: Because employees generally shouldn't be hiding their activity using TOR
Speaker 1: for work stuff exactly.
Speaker 3: There's usually no legitimate business need, so detecting it could
Speaker 3: indicate policy violations or even malicious activity like data exfiltration
Speaker 3: or command and control channel.
Speaker 1: Okay, that makes sense, understand it to detect it.
Speaker 3: The guide explains onion routing briefly, how tour encrypts traffic
Speaker 3: and bounces it through multiple random relays to hide the
Speaker 3: source and destination, and.
Speaker 1: It warns about running an exit relay.
Speaker 3: Definitely, big legal disclaimer there. Exit relays are where the
Speaker 3: tour traffic pops out onto the regular internet, so you
Speaker 3: could be blamed for what others do through your exit node.
Speaker 1: Good warning. It also mentions law enforcement uses TOR too.
Speaker 3: Sometimes yeah, for investigations anonymous tip lines things like that,
Speaker 3: and critically it advises don't do anything illegal and don't
Speaker 3: log into personal accounts if you're using tour for anonymity.
Speaker 2: Common sense, but.
Speaker 1: Important, absolutely so setting up Tour on our analysis system.
Speaker 3: The guide covers installing Tour itself, plus a helper tool
Speaker 3: called privoxy sox it's a web proxy here. It's used
Speaker 3: as a middleman to easily forward web browser traffic into
Speaker 3: the tour network, which listens on a soocks port.
Speaker 1: How's install work?
Speaker 3: Add the Tour project's repository ear system, import their signing key,
Speaker 3: update packages, then APT install tor, guipdb, torsosdeb, dot Tour project,
Speaker 3: dot org, desh gearing pretty standard package. Install a provoxy
Speaker 3: just APT install privoxy simple enough.
Speaker 1: How do they connect? How do you tell provoxy to
Speaker 1: use Tor?
Speaker 3: You edit provoxies, canfig file, et cetera. Provoxes can fig
Speaker 3: add one line at the end, forward socks five local
Speaker 3: host point nine zero five zero zero that tells it
Speaker 3: to send traffic to tours default soocks port ninety fifty
Speaker 3: running on the local machine. The guide also suggests commenting
Speaker 3: out the log file line, then restart the provoxy.
Speaker 1: Okay, installed, configured, How do you actually use it? The
Speaker 1: guide mentioned torsocks.
Speaker 2: Yeah, torsocks is neat.
Speaker 3: You just run torsocks command and it tries to force
Speaker 3: that command's network traffic through tour. The guide shows an
Speaker 3: example with.
Speaker 1: Curl, but not everything works with torsocks.
Speaker 3: Right, especially graphical things like web browsers. For those, you
Speaker 3: often need to go into the browser's network settings and
Speaker 3: manually configure the SCKS five proxy point it to local
Speaker 3: host port ninety fifty.
Speaker 1: The guide then shows a script tour switch to toggle
Speaker 1: tour on and off easily. That sounds useful, super useful.
Speaker 3: It uses x settings to change the system wide proxy
Speaker 3: settings for Genome desktops and system cordal to start stop
Speaker 3: the tour in provoxy services.
Speaker 2: Saves a lot of typing, and.
Speaker 1: It provides the script code how to make it executable
Speaker 1: with chew mode. Even handles potential ownership issues YEP, and it.
Speaker 3: Covers letting a regular user run this script without needing
Speaker 3: the pseudo password every time.
Speaker 1: How editing the sudoer's file gotta be careful.
Speaker 3: They're very careful use with pseudo always. It checks syntax
Speaker 3: before saving. The guy gives example lines to add allowing
Speaker 3: specific commands system sort, telecorner, stop, status, et cetera for
Speaker 3: a user without a password.
Speaker 1: Prompt Finally installing the Tour browser itself.
Speaker 3: Yeah, that's the prepackaged browser designed for Tour. Simple install
Speaker 3: apt get install Tour Browser launcher. Then you run Tour
Speaker 3: Browser Launcher as a normal user, not root.
Speaker 1: So now we can generate Tour traffic on our.
Speaker 3: Network exactly, which means we can test the Zeke signatures
Speaker 3: designed to detect it, which we'll get too later.
Speaker 2: Helps you understand it and spot it.
Speaker 1: Okay, Zeke is capturing We understand Tour now making sense
Speaker 1: of all that data. Enter the ELK stack, Elastic Search,
Speaker 1: log Stash, Cabana.
Speaker 3: Right, the powerhouse trio for log management and analysis, open source,
Speaker 3: very flexible, scalable.
Speaker 1: Let's break them down. Elastic Search is the search engine
Speaker 1: the database sort of.
Speaker 3: Yeah, It's a search and analytics engine based on Lucine,
Speaker 3: highly scalable, distributed. Its stores and indexes all the data
Speaker 3: so you can search it incredibly fast.
Speaker 2: It's the heart of.
Speaker 3: ELK and Stash the data processor exactly. Think of log
Speaker 3: Stash as the data pipeline or like the prep station.
Speaker 3: It ingests data from many sources filebeat for instance, then
Speaker 3: it can parse it clean.
Speaker 2: It up, enrich it.
Speaker 3: Enrich it how like adding GOIP info based on an
Speaker 3: IP address or translating cryptic log codes into human readable text.
Speaker 3: It uses things called grock patterns to understand structured or
Speaker 3: even unstructured logs. Then it sends the processed data to
Speaker 3: elastic Search.
Speaker 1: And Cabana is the shiny front end the dashboard.
Speaker 2: That's it.
Speaker 3: Cabana talks to elastic Search and lets you build visualizations charts, graphs, maps, tables,
Speaker 3: lets you explore the data interactively. It's how you see
Speaker 3: the patterns and anomalies.
Speaker 1: The guide also brings in Filebeat. What's its role?
Speaker 3: Filebeat is a lightweight agent, a shipper. You install it
Speaker 3: on servers where logs are generated. Its job is just
Speaker 3: to collect those logs and send them efficiently, either straight
Speaker 3: to elastic search or to log stash for that extra processing.
Speaker 1: Why use filebeat instead of just having logstash collect directly.
Speaker 3: Filebeat is much lighter, uses fewer resources on the source machine.
Speaker 3: It also has pre built modules for common log types
Speaker 3: like zeke logs, which simplifies setup. And it has this
Speaker 3: back pressure sensitive thing, meaning it won't flood log Stash
Speaker 3: or elastic Search if they get temporarily overloaded.
Speaker 1: Okay, so the flow is typically zeke writes logs, Filebeat
Speaker 1: reads logs sends to either log stash to elastic Search
Speaker 1: or elastic Search directly, then Kibana reads from elastic Search
Speaker 1: for visualization.
Speaker 3: That's the common pattern. The guide then walks through installing
Speaker 3: ELK plus filebeat, big warning, use the exact same version
Speaker 3: for all of them, avoids headaches.
Speaker 1: Right for elastic Search, add the elastic key in repo
Speaker 1: app to install elastic Search, then enable journal qualcogging. Why
Speaker 1: is that needed?
Speaker 2: By default?
Speaker 3: Elastic Search is a bit quiet in the main system logs.
Speaker 3: The guide shows modifying its service file elastic Search stop
Speaker 3: service to remove the quiet flag. Makes troubleshooting way easier
Speaker 3: using journal calls. Then you check it's running with corol
Speaker 3: local hosts point nine to two zero zero, and we.
Speaker 1: Need Java, open jdk.
Speaker 3: YEP, elastic Search and logs Dash run on Java. The
Speaker 3: guide recommends open jdk eight for the versions it discusses.
Speaker 3: Simple app to install open Jdk eight.
Speaker 1: Jdk log Stash install is similar, but it doesn't start automatically.
Speaker 3: Correct install the package, but you need to explicitly start
Speaker 3: the service. The guide shows the commands and where the
Speaker 3: config files live.
Speaker 1: Kubana install dot enable and start the service. Configure Kobana
Speaker 1: dot AML. What are the key settings there?
Speaker 3: Server dot port usually five six oh one, serve it
Speaker 3: dof host often local host or zero point zero zero
Speaker 3: zero to listen on all interfaces, and crucially elastic search
Speaker 3: dot hosts, which tells Kubana where to find elastic Search
Speaker 3: usually http dot local host, dot nine two Z or
Speaker 3: A zero and.
Speaker 1: Filebeat install enable it to start on boot okay stack
Speaker 1: installed now making it work with Zeke.
Speaker 3: The guide shows two main ways. First the simpler one
Speaker 3: filebeat send z clogs directly to elastic search.
Speaker 1: How is that configured?
Speaker 3: You edit filebeat dot AML, tell it where z clogs are, opseclogs,
Speaker 3: current dot log usually enable to built in filebeat z module.
Speaker 3: Then configure the output dot elastic search section with your
Speaker 3: elastic search address.
Speaker 1: And what changes on the zke side. For this direct method.
Speaker 3: You need to tell Zeke to output logs in JSON
Speaker 3: format and importantly use eph time stamps that's the number
Speaker 3: of seconds since nineteen seventy. You modify aii dot z
Speaker 3: and local dot z to set this up. The Kabana
Speaker 3: zke module expects that format.
Speaker 1: Then restart everything, go into gabona, create a filebeat index
Speaker 1: pattern and.
Speaker 3: Boom, you should see the pre built zke overview dashboard
Speaker 3: populated with your data instant visibility.
Speaker 1: Cool. But there's a second, more powerful method using logsdash.
Speaker 3: Yes, filebeat tas logsdash elastic search. This lets you do
Speaker 3: more sophisticated processing in logsdash.
Speaker 1: What changes for zke in this case timestams right.
Speaker 2: For the logstash route.
Speaker 3: You can figure a zeke jets an output again, but
Speaker 3: this time use ISOSO eight six to oh one time stamps.
Speaker 3: The more standard yy y y m M d d
Speaker 3: t h m s SC's format set that in.
Speaker 1: Local dot z and logstash needs configuring to receive from
Speaker 1: filebeats exactly.
Speaker 3: You edit pipelines dot mL to define the pipeline maybe
Speaker 3: tweet logstash dot mL.
Speaker 2: The core is a new config file, say zke dot com.
Speaker 1: Well goes in zeke dot com.
Speaker 3: An input section using the beats plugin listening on a
Speaker 3: port like five thousand and one. Then filter plugins, remove headers,
Speaker 3: parse json, use the date filter for the isotimestamp. Crucially,
Speaker 3: add the geop filter for location data. Maybe translate constate codes.
Speaker 3: You take field types, rename fields.
Speaker 2: Lots of power.
Speaker 3: There finally an output section pointing to elastic search.
Speaker 1: So filebeat needs to send to logstash port five thousand
Speaker 1: and one instead of elastic Search.
Speaker 3: Correct change the output section and filebeat dot aml from
Speaker 3: elastic search to logstash, specifying hosts Localhost dot five zero
Speaker 3: zero one, test the config, restart everything.
Speaker 1: Then in cabana, create a logfash index pattern yep.
Speaker 3: And now, because logstash added the goip data, you can
Speaker 3: build visualizations like coordinate maps showing traffic origins. The guide
Speaker 3: also adds a good troubleshooting tip. If data isn't showing upright,
Speaker 3: sometimes delete it and recreating the index pattern in kipana
Speaker 3: fixes it.
Speaker 1: Okay, Zeke is logging, elk is processing and visualizing, but
Speaker 1: Zeke isn't really alerting yet. Is it just logging connections
Speaker 1: each TTP, et cetera. We need signatures for active.
Speaker 3: Detection, exactly signatures. Tell Zeke hey, if you see the
Speaker 3: specific pattern, generate a notice. It moves Zeke from passive
Speaker 3: observation to active alerting.
Speaker 1: The guide points to installing signatures from GitHub.
Speaker 3: Yes, there's a repository linked you get clone it, then
Speaker 3: run and install dot Sher script provides this copies the
Speaker 3: signature files into the right place in your Zeke installation
Speaker 3: op zeek share Zeke site.
Speaker 1: Usually important warning from the guide here back up your
Speaker 1: existing site directory.
Speaker 3: First, absolutely crucial, especially local dot Zeke. That install script
Speaker 3: might overwrite your local customizations if you're not careful.
Speaker 2: Back up first.
Speaker 1: The guide then lists like forty eight example signatures from
Speaker 1: that repo.
Speaker 3: That's a lot it is, and it briefly explains each one.
Speaker 3: Some are basic canfig checks, make sure certain scripts are
Speaker 3: loaded and Jason logging is on. Others are more detection focused,
Speaker 3: like what scan detection, YEP scan dot seek also detect
Speaker 3: trace route detecting vulnerable software advertised by servers, noticing when
Speaker 3: software versions change unexpectedly, finding Windows, reverse shells, sequel injection attempts.
Speaker 1: Wow, okay, it looks really comprehensive. Signatures for specific protocols FTP, SMTP, SSH,
Speaker 1: HTTP detecting web apps.
Speaker 3: Tracking known good hosts and services, validating SSL SERTs, detecting
Speaker 3: SSH brute forcing, flagging interesting host name.
Speaker 1: Hashing all transmitted files, detecting non malicious file hashes. MHR
Speaker 1: heart bleed detection.
Speaker 3: Even yeah, the heart bleed one comes with the performance warning,
Speaker 3: though it's intensive. Also asset tracking, VLNMIC logging, spotting, clear text,
Speaker 3: HTTP basic.
Speaker 1: Off, and the tour detection we talked about.
Speaker 3: DDP scans, detecting web directory modifications, more, SSH attack detection,
Speaker 3: a whole data exfiltration detection.
Speaker 1: Framework, CRYPTO minding detection, DNS tunneling, RP.
Speaker 3: Monitoring, SMTT analysis, DNS zone transfer attempts looking for potential
Speaker 3: credit card numbers, and plaintext with a redaction option thankfully,
Speaker 3: FTP brute force HTTP stalling attacks, general HTTP impacts, finding
Speaker 3: passwords sent over clear HTTP.
Speaker 2: It's a really solid starting set.
Speaker 1: Okay signature is installed. Any zke reconfiguration needed.
Speaker 2: The guide mentions two things.
Speaker 3: One ad port ninety fifty CCP towards default to the
Speaker 3: sl ports set in Zeke's SSL canfig. This helps Zke
Speaker 3: analyze encrypted tour traffic.
Speaker 1: Makes sense.
Speaker 3: The other an option in theh GTP canfig to actually
Speaker 3: capture passwords sent via basic authentication. The guide mentions it exists,
Speaker 3: but rightly avoids recommending turning it on in production. Logging
Speaker 3: plaintext passwords bad.
Speaker 1: Idea, very bad idea. Okay, signatures are in Zeke potentially tweaked.
Speaker 1: How do we see the alerts?
Speaker 2: After any config change.
Speaker 3: You go to Zeke's bin directory, run dot ZULC install
Speaker 3: them the Z two hell deploy. This loads the new
Speaker 3: config and restart zke. Check status with ztail status.
Speaker 1: And the alerts themselves appear where an elk.
Speaker 2: Primarily in the notice dot log.
Speaker 3: That's where Zeke writes these alerts generated by the signatures.
Speaker 3: So in Kibana you'd filter for logit dot notice or
Speaker 3: look for the notice dot log source file if using
Speaker 3: filebeat modules.
Speaker 1: The guide gives examples like seeing an nmap scan alert.
Speaker 3: Yeah, or alerts about large file transfers happening after hours,
Speaker 3: you'd see the show up as documents in qubana source
Speaker 3: from notice dot log. And of course you can still
Speaker 3: tail dh fndice dot log on the Zke box itself and.
Speaker 1: The concrete example analyzing tour traffic we generated earlier.
Speaker 3: Right start Zeke, fire up the Tor browser, visit some sites,
Speaker 3: then check notice dot log in cabana. You should see
Speaker 3: notices pop up. What kind of notices things like ipoddress
Speaker 3: identified using Tor based on unique SSL certificate characteristics. Tour
Speaker 3: uses often followed by SSL invalid server start notices, possibly
Speaker 3: referencing the same certificate fingerprint.
Speaker 1: And the guide even shows how to double check if
Speaker 1: an IP was a tour relay using the tor Project's
Speaker 1: exonerator website.
Speaker 3: Yep metrics dot tourproject dot org exonerator dot html. You
Speaker 3: put in the ipn date, it tells you if it
Speaker 3: was a known relay, then really closes the loop on
Speaker 3: verifying the alert.
Speaker 1: So this shows the signatures working actively flagging specific potentially
Speaker 1: risky traffic exactly.
Speaker 3: It turns Zeke into a much more proactive defense tool.
Speaker 1: Okay, nearly there. The guide finishes with a quick look
Speaker 1: at Kubana dashboards.
Speaker 3: Yeah, just emphasizing that Kubana is where you bring it
Speaker 3: all together visually. You create custom visualizations geoheat maps showing
Speaker 3: where traffic comes from, goes to top talkers on the network,
Speaker 3: top applications used, top destinations, maybe track misbites for network health,
Speaker 3: total data volume, and crucially summaries and trends of the
Speaker 3: notices Zeke generated.
Speaker 1: And you combine these onto a dashboard right.
Speaker 3: Arrange them all into one screen to create your custom
Speaker 3: SIME dashboard gives you that single pane of glass view
Speaker 3: of your network security posture built with these open source tools.
Speaker 1: Wow. Okay that was a lot, but incredibly useful. We've
Speaker 1: gone from installings Zeke, understanding Tour, setting up the whole
Speaker 1: ELK stack, processing logs, and now actively detecting threats with
Speaker 1: signatures and visualizing it all.
Speaker 2: It's a powerful combination.
Speaker 3: You really do get a foundational grasp of building this
Speaker 3: kind of open source IDM set up from the guide,
Speaker 3: Understanding Zeke, integrating with ELK, leveraging signatures like the Tour detection, it's.
Speaker 1: All there and for you listening, the learner. We hope
Speaker 1: this deep dive hit that sweet spot thorough but also
Speaker 1: you know, digestible, giving you those connections, those aha moments
Speaker 1: without getting totally lost in the weeds. Yeah.
Speaker 3: The goal is to show you can get really well
Speaker 3: informed about network monitoring using these free tools. It's not
Speaker 3: just for big companies with huge budgets. This guide provides
Speaker 3: a fantastic shortcut.
Speaker 1: Absolutely. So here's a final thought to chew on something
Speaker 1: building on this, How could the kind of visibility you
Speaker 1: get from this setup, seeing graffic flows, seeing alerts, how
Speaker 1: could that actually shape your organization's security policies, or improve
Speaker 1: how you respond when an incident does happen.
Speaker 2: That's the you'll pay off.
Speaker 3: We'd definitely encourage you to dig deeper into Zeke's features,
Speaker 3: explore more of Kebana's visualization power, and maybe just maybe
Speaker 3: think about writing your own Zeke signatures, tailored specifically to
Speaker 3: your network's unique risks and normal traffic patterns. That's where
Speaker 3: it gets really powerful.