Speaker 1: Welcome to the deep dive. Imagine your digital network is
Speaker 1: like a really complex fault Okay, now, picture new cracks
Speaker 1: forming every single day, often places you'd least expect, and
Speaker 1: there are unknown eyes constantly probing for weaknesses.
Speaker 2: Yeah, it's a constant battleground out.
Speaker 1: There, exactly. So today we're taking a deep dive into
Speaker 1: the critical world of network performance and security. Our mission,
Speaker 1: we want to pull out the most crucial, the most
Speaker 1: actionable insights from Chris Chapman's really foundational book Network Performance
Speaker 1: and Security, Testing and analyzing using open source and low
Speaker 1: cost tools.
Speaker 2: It's a great source packed with practical.
Speaker 1: Stuff, it really is. And this isn't just about theory, right.
Speaker 1: Our goal is to give you a practical roadmap. Think
Speaker 1: of it as a shortcut to understanding how to spot vulnerabilities,
Speaker 1: actually harden your infrastructure and even test its resilience.
Speaker 2: Now without getting totally overwhelmed by all the technical details.
Speaker 1: Precisely, we'll uncover some surprising facts and really practical steps
Speaker 1: that are directly relevant to you listening right now, because,
Speaker 1: let's face it, in a world that depends entirely on
Speaker 1: digital connections, your quality of experience, your productivity, even your
Speaker 1: data is safety. It all hinges on a network that
Speaker 1: secure and performs well.
Speaker 2: Absolutely, whether you're prepping for a big meeting, trying to
Speaker 2: stay current, or just curious.
Speaker 1: Yeah, if you fit any of those, this deep dive
Speaker 1: is definitely for you. Okay, So let's unpack this core truth.
Speaker 1: The sources really highlight our networks. They're under continuous assault,
Speaker 1: and not just from outside attackers, but often from within
Speaker 1: what we mistakenly call a trusted zone.
Speaker 2: That internal threat is often underestimated totally.
Speaker 1: And what's really unsettling is this idea of the unknown unknown.
Speaker 1: So those devices, those configurations we don't even realize are
Speaker 1: on our.
Speaker 2: Network lurking there, which brings up a critical point. What
Speaker 2: happens when those attacks or maybe just poor performance actually
Speaker 2: impacts you. We're all used to what the book calls
Speaker 2: the web dial tone expectation.
Speaker 1: Right, the idea that it's just always there, always on, predictable.
Speaker 2: Exactly, and when you hit a four h four error
Speaker 2: where things are just slow, it's not just annoying, it
Speaker 2: directly impacts productivity. Chapman points out if authentication takes more
Speaker 2: than four seconds, or a web page more than seven seconds.
Speaker 1: To load, people just leave, They click away.
Speaker 2: Most users just abort. Think about that loss of efficiency.
Speaker 2: Even voice quality like on a VOYIP call has a benchmark,
Speaker 2: the MOS score. You really want that at four point
Speaker 2: two or higher. Anything less feels off.
Speaker 1: Okay, and here's where it's really interesting for me, this
Speaker 1: whole concept of trust in security. Ah Chatman makes this
Speaker 1: really powerful statement. He says trust is a non controllable,
Speaker 1: non measurable assumption that someone will always do the right thing.
Speaker 1: He basically calls it soft security.
Speaker 2: It's intangible, isn't it. You can't configure trust exactly.
Speaker 1: And then there's this alarming statistic he includes sixty percent
Speaker 1: of employees who are fired have been found to steal data.
Speaker 2: Wow, sixty percent.
Speaker 1: Yeah, So, relying purely on trust, it's just fundamentally incompatible
Speaker 1: with a robust security policy. So for you listening, you
Speaker 1: expect your network to work flawlessly. Sure, but understanding these vulnerabilities,
Speaker 1: these well unrealistic expectations about trust, that's crucial for being
Speaker 1: proactive about your own digital safety day to day.
Speaker 2: Couldn't agree more.
Speaker 1: So, Okay, if trust is bad for security, then visibility
Speaker 1: must be good. Right.
Speaker 2: Visibility is everything, It's the foundation So the.
Speaker 1: First absolutely critical step is getting organized with a thorough
Speaker 1: network audit. Our source really drives home this point. What
Speaker 1: you think is on your.
Speaker 2: Network can be worlds apart from what's actually there, right.
Speaker 1: And it only takes one undocumented, maybe unpatched device, that
Speaker 1: old PC in the lab everyone forgot about, or a
Speaker 1: private server someone stuck under a.
Speaker 2: Desk, uh huh, the classic shadow it.
Speaker 1: Exactly, that becomes the perfect beachhead for malware or bot nets.
Speaker 1: And then you're looking at a massive, expensive cleanup job.
Speaker 2: And the real insight you get from doing this exhaustive audit,
Speaker 2: it isn't just knowing what you have, it's realizing how
Speaker 2: much which you didn't know you had.
Speaker 1: That's a great way to put it, turning those unknown
Speaker 1: unknowns into.
Speaker 2: Nones precisely, that's your first real line of defense and
Speaker 2: the scope of this audit, while it's pretty comprehensive, you
Speaker 2: need to document basically every single device that touches your network.
Speaker 1: Okay, break that down. What kind of devices?
Speaker 2: Well, first host assets, think fixed PCs, laptops, tablets, smartphones.
Speaker 2: You need the basics, make model, but also IP address
Speaker 2: and massy address, the OS version, all the installed.
Speaker 1: Software approved and unapproved.
Speaker 2: Oh absolutely, you need to know what's actually running and
Speaker 2: even who owns the device. Then you've got mobile assets.
Speaker 2: These are trickier because they come and go.
Speaker 1: You have laptops phones, right, The.
Speaker 2: Book suggests something pretty clever placing asset tags inside the
Speaker 2: battery case for laptops harder to remove. Helps with tracking.
Speaker 1: That's smart, Okay? What else?
Speaker 2: Virtualized servers they add another layer You need more than
Speaker 2: just standard server stuff. Think VM profiles, snapshot states, the
Speaker 2: data stores they're attached to, and the whole network functions
Speaker 2: of virtu ualization chain. That's NFV where network services run
Speaker 2: in software right up to the physical network card.
Speaker 1: So really deep visibility into the virtual layer.
Speaker 2: Two, you have to tools like HWI, NFO or just
Speaker 2: built in system info commands are key here and don't
Speaker 2: forget hypervisor admin accounts critical to document those.
Speaker 1: Got it? What about the network gear itself?
Speaker 2: Yep, network element objects, switches, routers again, make model adamin credentials,
Speaker 2: port types like is it one gig or ten gig?
Speaker 2: And what connects? Where you're basically drawing a living network
Speaker 2: map and you need to version control the configurations so
Speaker 2: you track every single change.
Speaker 1: Okay, that makes sense, like source control for your network.
Speaker 2: Configure kind of Yeah. And finally, and this is often
Speaker 2: overlooked information assets your data house. So most places have
Speaker 2: really weak rules about where data is stored. Chatman stresses
Speaker 2: classifying info maybe level ABC, with strict policies for each
Speaker 2: like level A data your most sensitive stuff. It can
Speaker 2: cannot be stored on a local PC, never in a
Speaker 2: public cloud, not accessible from the Internet period.
Speaker 1: That's really strict, but necessary if you're serious about protecting it.
Speaker 2: Yes, okay, that is a ton of information to gather
Speaker 2: and manage. How do you keep track of it all? Yeah,
Speaker 2: you definitely need a system. The book points towards needing
Speaker 2: a network management system in NMS. It actually recommends spice
Speaker 2: works is a good open source option.
Speaker 1: Spie works. Okay, is setting that up complicated?
Speaker 2: It needs to be done strategically. You need a dedicated
Speaker 2: server for it, pretty high end and definitely isolated, probably
Speaker 2: a modern Windows server machine.
Speaker 1: And you put that somewhere super secure.
Speaker 2: Absolutely in a very secure zone. But here's the counterintuitive part.
Speaker 2: You don't typically install firewall software directly on the NMS
Speaker 2: server itself.
Speaker 1: Really, why not?
Speaker 2: You want to minimize its own attack surface. Instead, you
Speaker 2: carefully open specific pinholes point security policies on your internal
Speaker 2: firewalls to let the NMS scan the network segments it
Speaker 2: needs to.
Speaker 1: So the protection is on the surrounding firewalls, letting the
Speaker 1: NMS do its job exactly.
Speaker 2: It needs tools like windp cap and a MIP installed
Speaker 2: two for standing. But the big takeaway from the audit
Speaker 2: process is this knowing what you have is the absolute
Speaker 2: fundamental layer of defense.
Speaker 1: Without it, you're just You're.
Speaker 2: Fighting blind and just one forgotten device can bring the
Speaker 2: whole thing down.
Speaker 1: Okay, so audit complete, you have this incredibly detailed picture
Speaker 1: of your network. What's next?
Speaker 2: Right now? You lock it down, harden the infrastructure itself.
Speaker 2: And this means really moving beyond that old simplistic trusted
Speaker 2: versus untrusted mindset.
Speaker 1: You mean treating everything is potentially untrusted pretty much.
Speaker 2: It's about internal segmentation, breaking your network into smaller, more
Speaker 2: defensible zones, even internally.
Speaker 1: So how does that look in practice?
Speaker 2: Well, it applies everywhere from the edge right to the core.
Speaker 2: For core network hardening, the rule is simple but powerful.
Speaker 2: If you don't absolutely need a service or protocol running,
Speaker 2: turn it off.
Speaker 1: Get rid of the unnecessary stuff.
Speaker 2: Exactly. Disable things like telnet old routing protocols like RIP
Speaker 2: if you're not using them. Unencrypted HTTP management interfaces just
Speaker 2: reduce the attack surface.
Speaker 1: What about managing the devices?
Speaker 2: Always always encrypt management sessions use SSH, configure it robustly,
Speaker 2: set session timeouts, limit log in attempts. Basic hygiene, but
Speaker 2: critical and logging.
Speaker 1: You mentioned that earlier.
Speaker 2: Critical logging is huge for incident response for forensics, but
Speaker 2: it's not just about having logs. They need to be
Speaker 2: time correlated across all devices.
Speaker 1: Ah, so you can piece together what happened when precisely.
Speaker 2: That means you need a dedicated, accurate NTP time source
Speaker 2: like a gpscinc server and a centralized cyslog server. Both
Speaker 2: of those need to be in a secure core zone themselves.
Speaker 1: Okay, what about protecting against fake traffic spoofing?
Speaker 2: Good question. Anti spoofing protection is vital, especially at the edge,
Speaker 2: but also useful internally things like unicast reverse path forwarding
Speaker 2: or URFP.
Speaker 1: What does that do?
Speaker 2: It basically checks if the source IP address on an
Speaker 2: incoming packet is actually reachable via the interface it arrived on.
Speaker 2: Helps block packets with forged source ips. And IP source guard,
Speaker 2: which uses DHCP snooping data to build dynamic access lists,
Speaker 2: binding ips to mday's and ports. Even just enabling basic
Speaker 2: port security on switches helps catch MAC spoofing attempts.
Speaker 1: So multiple layers there. Now, what about performance? People always
Speaker 1: complain about slowness.
Speaker 2: Right, optimizing performance with QoS quality of service. Often just
Speaker 2: throwing more bandwidth at a problem isn't the fix.
Speaker 1: Yeah, upgrades don't always help.
Speaker 2: Instead, classifier traffic, put services into buckets, network abmin, business critical,
Speaker 2: business standard, best effort, whatever makes sense for you. Then
Speaker 2: use QoS like diffserve markings at layer three to tell
Speaker 2: the network what's important. So even if some malware or
Speaker 2: a botnet starts hogging bandwidth.
Speaker 1: The network knows to prioritize the critical stuff exactly.
Speaker 2: Your important applications stay responsive.
Speaker 1: What about wide area networks connections between sites WAN security?
Speaker 2: This is a big one. We tend to think of
Speaker 2: our WAN links as inside and trusted.
Speaker 1: Because they connect our offices. Right.
Speaker 2: Yeah, but that's a dangerous assumption. The book is clear,
Speaker 2: treat your WAN as its own untrusted security zone.
Speaker 1: Okay, so encrypt everything.
Speaker 2: Strong encryption is non negotiable. Think AES two five six
Speaker 2: with robust hashing like SA five twelve using X point
Speaker 2: five zero nine certificates. Often this means dedicated hardware encryption
Speaker 2: boxes between sites.
Speaker 1: Right. How about wi fi?
Speaker 2: Always a headache organizational Wi Fi best practice? Think DMZ
Speaker 2: for wireless, set up two ssas one for internal trusted,
Speaker 2: use strong password, mixed case number symbols, and don't broadcast
Speaker 2: the sad name it it YEP, and then a separate
Speaker 2: guest network. It's okay to broadcast that one, but all
Speaker 2: guest traffic must be tunneled directly out to your Internet
Speaker 2: security zone, no access to the internal network, and make
Speaker 2: them accept terms. Maybe use two step authentication if possible
Speaker 2: for guests.
Speaker 1: Okay, separating those makes a lot of sense. What about
Speaker 1: the main Internet connection itself?
Speaker 2: Your external firewall and Internet connection. This is where you
Speaker 2: need serious hardware. The book recommends high end firewalls, the
Speaker 2: kind based on A six or.
Speaker 1: FPGA's dedicated hardware for speed, right.
Speaker 2: Because they need to do deep packet inspection and handle
Speaker 2: lots of connections without slowing down. They let you do
Speaker 2: really granular control too, like maybe allow Skype chat but
Speaker 2: block Skype file transfers.
Speaker 1: Ah control within the application itself.
Speaker 2: Yes, and use firewalls between your internal zones too to
Speaker 2: sandbox risk. For remote users, IPsec VPN is generally preferred
Speaker 2: over SSLVPN, using per user authentication and certificates and all
Speaker 2: that remote traffic needs to be inspected by the firewalls,
Speaker 2: intrusion prevention and dedoss engines.
Speaker 1: One last thing you mentioned, yeah printers really?
Speaker 2: Oh yeah, locking down printers. People forget them, but they're
Speaker 2: basically network connected computers with their own vulnerabilities. Interfaces, different protocols.
Speaker 1: Okay, so what do you do?
Speaker 2: Treat them seriously? Enable HTTPS only for the web management interface,
Speaker 2: Use strong passwords that you actually rotate. Restrict SMMP access
Speaker 2: so only your NMS can talk to it. Disabled telnet
Speaker 2: if it's somehow still enabled. Use secure printing protocols like
Speaker 2: IPP over TLS.
Speaker 1: Oh wow. Okay. The big picture here is definitely layers.
Speaker 2: It absolutely is a truly secure infrastructure is defense in depth.
Speaker 2: Every device, every protocol, every potential path for traffic needs
Speaker 2: scrutiny and being aggressive about disabling services you don't need.
Speaker 2: That drastically shrinks the area attackers can target right.
Speaker 1: Less surface area means fewer potential holes.
Speaker 2: You got it.
Speaker 1: Okay, let's shift focus a bit. Let's talk about the endpoint,
Speaker 1: the client computer. For many of us, that's a Windows machine,
Speaker 1: and the sources are really clear on this. The client
Speaker 1: is often a major point of attack, maybe even the
Speaker 1: weakest link in the whole chain.
Speaker 2: It frequently is. Unfortunately, it's where the user interacts directly,
Speaker 2: clicks on things.
Speaker 1: So hardening that client is crucial. What are the key steps.
Speaker 2: It's fundamentally about minimizing that attack surface and maximizing the
Speaker 2: built in protections. First off, software control big one. Users
Speaker 2: should never have administrator or even power user rights.
Speaker 1: Full stop, standard user accounts only. Yes.
Speaker 2: Instead, you use things like software restriction policies pushed out
Speaker 2: via group policy, maybe with w MII filtering for targeting.
Speaker 2: You basically whitelist only the approved applications that are allowed
Speaker 2: to run.
Speaker 1: So users literally can install random stuff they.
Speaker 2: Download exactly, no accidentally installing infected executables or those annoying
Speaker 2: browser toolbars that come bundled with things. Next, User account
Speaker 2: control UAC.
Speaker 1: That pop up everyone loves to hate.
Speaker 2: That's the one. Turn it up to its highest setting. Yes,
Speaker 2: it can be annoying, but it adds a really crucial
Speaker 2: layer prompting for authorization before software installs or system changes.
Speaker 2: It stops a lot of automated malware in its tracks.
Speaker 1: Okay, makes sense. What about the networking side of Windows itself?
Speaker 2: Yeah, Hardening Windows networking disable unnecessary stuff. If you're not
Speaker 2: using IPv six internally, turn it off on the clients.
Speaker 2: Same for things like IGMP or Universal Plug and Play
Speaker 2: UPMP is notoriously problematic for security.
Speaker 1: How do you check what's running?
Speaker 2: You want to minimize listening ports, run netstat ab and
Speaker 2: en in the command prompt that shows you which executables
Speaker 2: are listening on which ports. If you see something listening
Speaker 2: that you don't recognize, our need, investigate and remove it.
Speaker 1: Good tip. What about other Windows services?
Speaker 2: Right? Disabling unnecessary services? Windows comes with a lot of
Speaker 2: services running by default. There are great resources online, like
Speaker 2: the black Viper blog mentioned in the source that list
Speaker 2: services and whether they're typically safe to disable. Think about
Speaker 2: things like IP helper, offline files, parental controls if it's
Speaker 2: corporate machine, fax service, home group listeners, Bluetooth support if
Speaker 2: you don't use bluetooth, proper roles. If you don't need it,
Speaker 2: disable it again. Reducing the attack surfaces.
Speaker 1: Okay, browsers are obviously huge, too.
Speaker 2: Huge browser heartening. Ideally standardize the organization on one browser.
Speaker 2: The source recommends Chrome because it removed the old insecure
Speaker 2: NPPI plugin system, but whatever you choose, the absolute crucial
Speaker 2: thing is enable automatic updates, always be patched always. Then
Speaker 2: configure the settings tightly, for ie, set the internet zone
Speaker 2: to high, enable protected mode, smart screen, ActiveX filtering, tracking protection,
Speaker 2: turn off third party browser extensions unless explicitly.
Speaker 1: Approved, and for Chrome or Firefox.
Speaker 2: Similar principles. Configure privacy settings, aggressively block third party cookies,
Speaker 2: enable fishing and malware protections, and do not track requests.
Speaker 2: And a big one, never allow the browser to save passwords.
Speaker 2: Convenience versus security. Security wins here.
Speaker 1: Good point. What about Java still a thing?
Speaker 2: Still a thing, still needs attention Java security. Keep it updated,
Speaker 2: but only from the official Java dot com site. Make
Speaker 2: sure only the latest version is installed, uninstall old ones
Speaker 2: in the Java control panel, set the security level too
Speaker 2: high or very high, and be very strict about adding
Speaker 2: exceptions to the security prompts. Only allow internal trusted applications
Speaker 2: if absolutely necessary.
Speaker 1: Okay, so these are all really concrete steps someone listening
Speaker 1: can take, maybe even check on their own machine.
Speaker 2: Absolutely, it's about transforming that potential weak link into a
Speaker 2: much more robust part of the overall network defense.
Speaker 1: All right, so we've audited, we've hardened the infrastructure, we've
Speaker 1: hardened the client. Feels like we've built a pretty solid fortress.
Speaker 2: It's a good start, But how do you know it's solid?
Speaker 2: How do you know the defenses actually work against real
Speaker 2: world techniques?
Speaker 1: Ah? Right? Testing? This is where penetration testing comes.
Speaker 2: In, exactly, penetration testing and deep traffic analysis. Because the attackers,
Speaker 2: they're sophisticated, they use multi stage attacks. They might be
Speaker 2: after data, trying industrial espionage, even engaging in cyber warfare.
Speaker 2: You have to test your defenses against those kinds of threats.
Speaker 1: So you need to think like an attacker to defend.
Speaker 2: Against themsolutely do understand our techniques. The book mentions things
Speaker 2: like knock down attacks, finding backdoors, multi step multi host
Speaker 2: attacks to spread bots, reconnaissance to gather info, scanning for
Speaker 2: open ports, gaining access, maybe creating hidden admin accounts, maintaining
Speaker 2: that access, and then covering their tracks, deleting logs.
Speaker 1: So how do you test against that well.
Speaker 2: The testing philosophy is key. Security audits aren't a one
Speaker 2: and done thing. They're perishable. They need to be done regularly.
Speaker 2: The source suggests monthly, which is pretty frequent, but definitely
Speaker 2: trigger one after any major network change or when a
Speaker 2: big new vulnerability is announced. And critically, never assume the
Speaker 2: internal network is safe. Test from the inside too. Threats
Speaker 2: can absolutely originate internally.
Speaker 1: Okay, what tools do you use for this? The book
Speaker 1: mentions Colie Linux.
Speaker 2: Yeah, Colilinux is sort of the Swiss army knife for this.
Speaker 2: It's a Linux distribution packed with security and penetration testing tools.
Speaker 2: One of the most powerful tools within it is.
Speaker 1: Metasploy metasploit heard of it? What does it do?
Speaker 2: It's an open source framework. It contains a huge database
Speaker 2: of known exports. You can search for exploits targeting specific
Speaker 2: software like Windows versions or applications like mysequel. You set
Speaker 2: your target, configure any options the exploit needs, and then
Speaker 2: you type exploit and.
Speaker 1: It tries to break in ethically of.
Speaker 2: Course, ethically yes, It launches the attack, and if it's successful,
Speaker 2: metasploit can deliver a payload. Often that's the.
Speaker 1: Mitipriter shell and that sounds bad.
Speaker 2: It is. The book calls it the keys to the Kingdom.
Speaker 2: It gives the tester or an attacker deep control over
Speaker 2: the compromise machine. They can run commands, browse files, even
Speaker 2: enable keyloggers to capture passwords or turn on remote desktop.
Speaker 1: Okay, scary stuff. So how do you protect against that
Speaker 1: kind of penetration attack?
Speaker 2: Protecting your assets requires that layered defense we talked about.
Speaker 2: For instance, use different vendors for your IDSPS systems, maybe
Speaker 2: one at the main internet edge, another vendor's product protecting
Speaker 2: the data center zone. Diversity helps catch things one might miss.
Speaker 2: Configure firewall rules with really strict pinholes. Only allow the
Speaker 2: specific protocols and ports needed for applications to work, drop
Speaker 2: and log everything else, especially unauthorized outbound traffic that can
Speaker 2: be a sign of compromise.
Speaker 1: What about on the switches?
Speaker 2: Use access control lists ecls on your distribution layer switches.
Speaker 2: Enforce your intended traffic flows. For example, make a rule
Speaker 2: that application servers are only allowed to talk to database
Speaker 2: servers on the specific ports they need and nowhere else.
Speaker 2: On Linux servers, use iptuples or NF tables.
Speaker 1: Firewalls, so controlling traffic flow internally.
Speaker 2: Is key, hugely important. But there's another piece understanding valid traffic.
Speaker 2: You need a baseline.
Speaker 1: What does normal look like?
Speaker 2: Exactly? You can't spot an attack if you don't know
Speaker 2: what normal traffic patterns are for your network. Document the
Speaker 2: expected protocols, source the destination IPS port numbers for your applications.
Speaker 2: So if suddenly your internal only application server tries to
Speaker 2: connect to a random IP address on the Internet.
Speaker 1: Using httcs, that's a huge red flag.
Speaker 2: Massive red flag. That baseline is critical context.
Speaker 1: Okay, how do you get that baseline? How do you
Speaker 1: see the traffic?
Speaker 2: Tools like wireshark, it's a fantastic free packet sniffer. Use
Speaker 2: it to capture traffic at strategic points near the core,
Speaker 2: at zone boundaries.
Speaker 1: And just look at packets flying by.
Speaker 2: You can, but it's more powerful than that. You can
Speaker 2: create capture filters to only grab specific traffic, like not
Speaker 2: net ten point one point zero two four to see
Speaker 2: traffic leaving your local subnet, and then use display filters
Speaker 2: to analyze the captured data. For example, that materpreter shell
Speaker 2: we mentioned it might use a specific suspicious user agent
Speaker 2: string in its web traffic. You can filter for that
Speaker 2: or look for custom HTTP headers maybe you've implemented internally
Speaker 2: as a sort of secret handshake to validate legitimate internal
Speaker 2: web traffic.
Speaker 1: Interesting can it find malware?
Speaker 2: It can help. You can do raw HGX searches with
Speaker 2: in packet data for known malware signatures. It also has
Speaker 2: GeoIP mapping, so you can see geographically where traffic is
Speaker 2: going to or coming from.
Speaker 1: Powerful toolout automated detection.
Speaker 2: That's where Snort comes in. It's a leading open source
Speaker 2: IDs SIS intrusion detection and prevention system. It analyzes traffic
Speaker 2: in real time against a set of rules, looking for
Speaker 2: patterns of attack like what kind of patterns, DDAs attempts,
Speaker 2: buffer overflows, port scans specific malware communication patterns. Chapman even
Speaker 2: details how to build a high performance appliance specifically for Snort,
Speaker 2: using fast CPUs, lots of RAM, and high speed Intel
Speaker 2: nies because deep packet inspection takes serious horsepower at high speeds.
Speaker 2: Where do you deploy Snort Definitely at your Internet edge,
Speaker 2: but also crucially between your internal security zones. You can
Speaker 2: figure it with your network layout home that external in
Speaker 2: its configuration file snort dot CoV it can log alerts
Speaker 2: to syslog or even a database.
Speaker 1: Okay, is there anything that ties these tools together?
Speaker 2: Yes, Security Onion it's a fantastic Linux distribution specifically designed
Speaker 2: for security monitoring. It integrates tools like s Nortai and
Speaker 2: other IDs called brow zeke log analysis tools, and visualization
Speaker 2: front ends like Snorby, so it's like an analytics platform exactly.
Speaker 2: It typically build a Security Onion sensor with powerful hardware,
Speaker 2: lots of storage for packet capture, strong CPUs, You can
Speaker 2: figure management and monitoring interfaces, enable the IDs engines. Bro
Speaker 2: is great for extracting files transferred over the network for
Speaker 2: a later analysis. Snorbe gives you a nice web interface
Speaker 2: to see alerts categorized by severity sensor protocol. You can
Speaker 2: set up email alerts for critical events, and another tool
Speaker 2: often used with it, Skullgill, lets you monitor events in
Speaker 2: real time and even reconstructs sessions, like seeing the commands
Speaker 2: and attacker tried during an FTP session.
Speaker 1: Wow, that's like looking over their shoulder pretty much.
Speaker 2: It's powerful for understanding exactly what happened or is happening.
Speaker 2: So yeah, this whole section really shows how sophisticated attacks are,
Speaker 2: but also how you can use these powerful tools, many
Speaker 2: of them open source to proactively test, detect, and offend.
Speaker 1: It's a whole different level of visibility in defense, it
Speaker 1: really is. Okay, so we've covered security pretty intensely, but
Speaker 1: the book title also mentions performance. How do we tackle that?
Speaker 1: How do we ensure that smooth, reliable quality of experience
Speaker 1: for users?
Speaker 2: Right? Because security is crucial, but if the network is unusable,
Speaker 2: that's a problem too. It's not just about raw speed
Speaker 2: like bandwidth numbers, It's about how it feels the.
Speaker 1: Quality of experience or QoE exactly.
Speaker 2: And testing this properly involves avoiding false positives. Vendor spec
Speaker 2: sheets like those RFC two five four four numbers they quote.
Speaker 2: They might not reflect your real world performance under your
Speaker 2: specific traffic conditions, So.
Speaker 1: Lab numbers aren't real world.
Speaker 2: Numbers, often not. Chapman has a great line test to
Speaker 2: the worst case and measure the best result. You need
Speaker 2: to generate traffic that actually emulates your network's behavior.
Speaker 1: How do you generate that test traffic?
Speaker 2: Austinato is a great open source tool for this. It's
Speaker 2: a multi stream traffic generator. It lets you build custom
Speaker 2: packets layer by layer, MME, IP, TCPUDP, headers. You can
Speaker 2: set different frame sizes from tiny sixty four byte ones
Speaker 2: up to jumbo frames, control the rate precisely. You can
Speaker 2: even strip it with Python for complex scenarios, so.
Speaker 1: You can mimic different kinds of application traffic precisely.
Speaker 2: And for just measuring raw throughput, jitter and packet loss
Speaker 2: between two points, IPERF three is the standard tool. You
Speaker 2: run it in server mode on one machine, client mode
Speaker 2: on another, and it tells you the actual TCP or
Speaker 2: UDP performance between them. Simple but essential.
Speaker 1: What about testing over distance like a whan, The experience
Speaker 1: there is often very different.
Speaker 2: Ah, Yes, you need wine emulation. You can't just test
Speaker 2: on your fast local land and assume it'll be the
Speaker 2: same for remote users. Tools like WAYNM, which is also
Speaker 2: open source, let you artificially introduce latency, jitter, packet loss,
Speaker 2: bandwidth constraints to simulate wine conditions.
Speaker 1: How do you know what values to simulate?
Speaker 2: The book gives some rules of thumb for latency. Figure
Speaker 2: about one millisecond for every one hundred kilometers of fiber distance.
Speaker 2: Then maybe multiply by one point three to account for
Speaker 2: real world paths equipment delays. For Internet VPNs, It suggests
Speaker 2: testing with maybe a worst case three percent packet loss
Speaker 2: to see how applications cope.
Speaker 1: Okay, so you simulate the bad conditions, then what then
Speaker 1: you need?
Speaker 2: Clear QoE benchmarks for web applications. Define what good means
Speaker 2: for you. For example, is a web page loading in
Speaker 2: under half a second good? Maybe over sixty seconds is poor.
Speaker 2: Define thresholds also track errors, distinguished between direct service errors
Speaker 2: like a four oh four where you might tolerate zero,
Speaker 2: and subtle errors maybe a graphical glitch where you might
Speaker 2: tolerate one per one thousand views.
Speaker 1: Having objective measures yes.
Speaker 2: So when users complain you have something to compare against.
Speaker 2: And when debugging QE issues you need a systematic approach.
Speaker 1: Where do you start?
Speaker 2: Talk to the user first, what did they expect? What
Speaker 2: actually happened? How often is it random, periodic? Is it
Speaker 2: an obvious error or just slow? Then check for recent
Speaker 2: network changes. Is the problem isolated to them or is
Speaker 2: it widespread? If it's isolated, start at their PC, new
Speaker 2: software installed, run a malware scan, check their TCP stack
Speaker 2: settings using netsch in TCP show global, look at CPU
Speaker 2: and RAM usage, check browser plugins or settings. Work outwards
Speaker 2: from the user.
Speaker 1: Logical troubleshooting process exactly.
Speaker 2: So this performance side is about having the right tools
Speaker 2: to simulate, measure and benchmark so you can sure the
Speaker 2: network isn't just secure but actually delivers that good quality
Speaker 2: of experience.
Speaker 1: That makes a lot of sense. Now, One of the
Speaker 1: really empowering things in Chapman's book is this idea that
Speaker 1: you don't always have to buy expensive proprietary boxes. He
Speaker 1: makes a strong case for building your own network elements
Speaker 1: using open source.
Speaker 2: He really does, and there are compelling reasons. Potentially better
Speaker 2: costs per megabit, using your budget, more efficiently and honestly
Speaker 2: often greater control and even security because you know exactly
Speaker 2: what's running.
Speaker 1: But can open source software on standard hardware really keep
Speaker 1: up these days?
Speaker 2: Yes, with modern multi core CPUs, fast RAM, and especially
Speaker 2: smart network interface cards and ices like the Intel ones
Speaker 2: mentioned by seven to ten, for four by five, five
Speaker 2: twenty for ten G plus open source driver technologies like
Speaker 2: DPTK or PFRNG, you can achieve line rate packet forwarding
Speaker 2: without needing specialized A six at least for many use cases.
Speaker 1: Okay, so what kind of elements can you build?
Speaker 2: He mentions a router, YEP, A router using something like VOS.
Speaker 2: It's Linux based, comes as an installable image or a
Speaker 2: virtual machine. It supports enterprise routing protocols like OSPF and
Speaker 2: BGP and has basic firewall capabilities. Too great for edge
Speaker 2: routing or internal segmentation. What about a switch, openb switch
Speaker 2: or OVS. It's a powerful open source virtual switch. You
Speaker 2: can create bridges, add physical or virtual ports, do vland tagging.
Speaker 2: It's heavily used in data centers, cloud environments for those
Speaker 2: NF chains we talked about, or as part of software
Speaker 2: defined networking with open flow.
Speaker 1: Okay load balancer. Those are usually expensive.
Speaker 2: You can build one. Zen looad Balancer ZLB is mentioned
Speaker 2: as an open source option. It gives you a virtual IP,
Speaker 2: a VIP that sits in front of a pool of
Speaker 2: back end servers. It can distribute to traffic using different
Speaker 2: methods like round robin or based on server load. Absolutely
Speaker 2: critical for high availability and maintenance.
Speaker 1: DHCP server seems basic but necessary, easy to do with
Speaker 1: open source.
Speaker 2: The book suggests the standard ic DHCP server on a
Speaker 2: Buntu Linux simple configuration file to define your IP address scopes,
Speaker 2: default router, DNS servers, then lock it down with basic
Speaker 2: firewall rules allowing UDP ports to sixty seven and sixty eight.
Speaker 1: And finally a web server stack.
Speaker 2: Yeah, for a standard web server setup, something like turnkey
Speaker 2: lampy is great. It's a pre integrated virtual appliance with Linux, Apache,
Speaker 2: Myseql and PHP already set up. It includes webmen for
Speaker 2: easy web based administration, making configuration even setting up SSL
Speaker 2: much simpler.
Speaker 1: So really, a whole range of core network functions can
Speaker 1: be built cost effectively with open source.
Speaker 2: Absolutely it opens up a lot of possibilities, giving you
Speaker 2: powerful secure solutions, often without the vendor lock in or
Speaker 2: high price tags.
Speaker 1: Okay, one final area. Let's say you're not building it yourself,
Speaker 1: you're evaluating a commercial product your service. How how do
Speaker 1: you make sure the vendor is actually delivering on security,
Speaker 1: not just giving you marketing fluff.
Speaker 2: Excellent question. You need to ask tough specific questions in
Speaker 2: your kindness request for proposal RFP or evaluation process like
Speaker 2: what well, first protocol stack verification? Don't just accept their claims.
Speaker 2: Demand a list of every single protocol stack their device
Speaker 2: uses internally, and crucially, ask for a fuzzing test.
Speaker 1: Report for each one. Fuzzing What's that?
Speaker 2: Fuzzing is an automated testing technique where you throw invalid,
Speaker 2: unexpected or random data at an input, in this case
Speaker 2: the protocol stat to see if it crashes or behaves unexpectedly.
Speaker 2: It's great for finding vulnerabilities like buffer overflows that attackers
Speaker 2: love to exploit. If they haven't fuzzed their stacks, that's
Speaker 2: a red flag.
Speaker 1: Okay, good one.
Speaker 2: What else malware mitigation ask about their anti malware capabilities
Speaker 2: if it's relevant to the product get reports. Ask how
Speaker 2: often their signature databases are updated, and importantly, ask about
Speaker 2: both poll schedules, how often the device checks for updates
Speaker 2: and push schedules how quickly they push out emergency updates
Speaker 2: for zero day threats.
Speaker 1: Understanding the update cadence makes sense.
Speaker 2: And maybe the most critical one. Mixed class attacks and
Speaker 2: services testing this is key. Don't just ask how it
Speaker 2: performs normally or how it blocks attacks in isolation. Ask
Speaker 2: them to provide test data showing valid application traffic performance
Speaker 2: with no attacks running, and then the same valid traffic
Speaker 2: performance while the device is simultaneously under attack or undergoing
Speaker 2: a security audit stand.
Speaker 1: Ah, so how does it perform under pressure exactly?
Speaker 2: You want to know were all the attacks actually blocked
Speaker 2: and crucially, how much did your legitimate traffic performance degrade
Speaker 2: while the device was busy fighting off the attack. Ideally,
Speaker 2: the answer should be all attacks blocked, zero degradation to
Speaker 2: valid traffic.
Speaker 1: That seems like a high bar it is.
Speaker 2: But that's what you should be aiming for and asking
Speaker 2: vendors to demonstrate. These aren't just casual questions. They're critical
Speaker 2: inquiries you need to make to ensure any new gear
Speaker 2: or code actually meets your securities standards and doesn't become
Speaker 2: your next vulnerability.
Speaker 1: That's really practical advice for evaluating vendors. Well, just like that,
Speaker 1: we've covered a huge amount of ground. We've journeyed through
Speaker 1: this really intricate landscape of network performance and security. We
Speaker 1: went from understanding those subtle impacts of just a slow
Speaker 1: web page load all the way to the pre sophisticated
Speaker 1: tactics of penetration testers. We've dug into the vital importance
Speaker 1: of audits, learned about hardening infrastructure and clients, and even
Speaker 1: saw the power of open source tools for building and testing.
Speaker 2: It really touches on the whole life cycle.
Speaker 1: It does, and hopefully for you listening, you now have
Speaker 1: a deeper understanding of those unknown unknowns we started with,
Speaker 1: and maybe a more practical toolkit to identify, analyze, and
Speaker 1: mitigate threats on your own networks.
Speaker 2: These aren't just abstract ideas, they're actionable insights exactly.
Speaker 1: This is stuff you can use to build a genuinely
Speaker 1: resilient network. So, as you reflect on this deep dis
Speaker 1: here's a final thought to leave you with, What unrecognized device,
Speaker 1: what forgotten policy? What unaudited private server lurking in your
Speaker 1: environment might just be the beachhead for the next attack.
Speaker 2: Yeah, where's your hidden vulnerability?
Speaker 1: And maybe more importantly, how will you use some of
Speaker 1: the knowledge from today to find it before an attacker
Speaker 1: does start that audit? Maybe re evaluate where your trust
Speaker 1: boundaries really are, and just keep exploring. Because its continuous
Speaker 1: battle for network security, it's one where knowledge truly is power.