Speaker 1: Imagine you're standing at the edge of this huge, complex
Speaker 1: digital landscape. Maybe you're a network admin, maybe just really
Speaker 1: curious about how it all works underneath, right, and suddenly
Speaker 1: you're just hit with this flood of info about network
Speaker 1: security vulnerabilities, exploits, all these scanning tools. It's overwhelming. How
Speaker 1: do you actually cut through that noise? How do you
Speaker 1: get smart about what really matters without you drowning?
Speaker 2: Well, that's exactly what we try to do here on
Speaker 2: the deep Dive. We're aiming to be that shortcut for you.
Speaker 2: We dig through a whole stack of sources on these
Speaker 2: really complex topics and pull out the most important insights,
Speaker 2: sort of turning that information overload into hopefully clear understanding.
Speaker 1: And today we're diving into the Network Scanning Cookbook. This
Speaker 1: isn't just theory, right, it's a really practical look at
Speaker 1: how two absolute powerhouse tools en MAP and NESSUS are
Speaker 1: used to genuinely understand network security exactly.
Speaker 2: We'll get to the essentials. What are these tools, why
Speaker 2: are they so crucial for dealing with today's digital threats,
Speaker 2: and how they can uncover some surprising weaknesses even in
Speaker 2: places you might not expect, like say, industrial control systems.
Speaker 1: Okay, so by the end of this deep dive, the
Speaker 1: idea is you'll not only get the core concepts, but
Speaker 1: you'll have those aha moments. You'll be able to really
Speaker 1: evaluate network security stuff critically.
Speaker 2: Let's get started right, Well, like any good cookbook, you
Speaker 2: start with the basics and a network security that's defining
Speaker 2: a vulnerability. Fundamentally, it's just a weakness, a flaw in
Speaker 2: a system or a device that an attacker could potentially exploit.
Speaker 2: Think of it like a door left unlocked, maybe a
Speaker 2: window latch that's broken.
Speaker 1: Got it, simple weakness. So network vulnerability scanning, that's basically
Speaker 1: the process of actively hunting for those weak spots across
Speaker 1: your whole network.
Speaker 2: That's it, clients, servers, routers, switches, everything connected.
Speaker 1: And with new critical vulnerabilities popping up seeming well daily,
Speaker 1: what's this so urgent for organizations? Why make it a
Speaker 1: real time thing?
Speaker 2: It's really about staying ahead of the curve. Organizations absolutely
Speaker 2: need procedures in place, real time procedures to find, analyze,
Speaker 2: and fix these issues before attackers find them.
Speaker 1: Right prevention exactly.
Speaker 2: It prevents potentially huge financial losses, protects their reputation, keeps
Speaker 2: systems updated, and crucially, you can't fix everything instantly, so
Speaker 2: it's also about smartly prioritizing which risks are the biggest threats.
Speaker 1: That's the classic problem, isn't it. You hear stories all
Speaker 1: the time where some major flaw goes unfixed for ages
Speaker 1: just because they didn't prioritize it correctly.
Speaker 2: It happens way too often.
Speaker 1: Now. The sources talk about two main kinds of scans.
Speaker 1: Can you break those down?
Speaker 2: Sure? So? First you have internal scans. These simulate what
Speaker 2: an insider could see, usually targeting private IP addresses inside
Speaker 2: the company network. Then you have external scans. These mimic
Speaker 2: an attacker coming from the Internet hitting your public facing
Speaker 2: IP addresses.
Speaker 1: Ah so inside and outside views.
Speaker 2: Precisely, and you absolutely need both for a complete security picture.
Speaker 2: It's like checking your house locks from the inside and
Speaker 2: walking around the outside to check the windows.
Speaker 1: Makes sense, and the scanning itself, it follows a pretty
Speaker 1: logical flow, right, like a three step recipe exactly.
Speaker 2: The first phase is discovery sometimes called host discovery. Okay,
Speaker 2: you got to find out what's actually live on the
Speaker 2: network first, no point scanning things that aren't even turned
Speaker 2: on or don't.
Speaker 1: Exist, right, avoid wasted effort exactly.
Speaker 2: Tools like end map and nessus are great for this.
Speaker 2: N MAP even has its script engine, the NSC, for
Speaker 2: really customized discovery.
Speaker 1: Okay, so step one find the live devices. What's next?
Speaker 2: Step two is port scanning. Once you know what's live,
Speaker 2: you need to check which doors, which ports are open
Speaker 2: on those devices, and it works differently depending on the
Speaker 2: protocol like TCP versus UDP. En map is really the
Speaker 2: master tool for figuring all that.
Speaker 1: Out, checking the doors and windows on the live houses.
Speaker 1: Got it?
Speaker 2: And the final step, the final, really crucial phase, is
Speaker 2: vulnerability scanning. This is where automated tools, especially nessa's, really
Speaker 2: come into their own how so well, They go beyond
Speaker 2: just seeing if a port is open. They actually try
Speaker 2: to look through that open port to find known issues,
Speaker 2: things like outdated software, vulnerable protocols, maybe even default admin
Speaker 2: passwords left unchanged.
Speaker 1: Ah.
Speaker 2: Imagine trying to manually check for thousands of known vulnerabilities
Speaker 2: across one hundred, maybe thousands of devices almost impossible.
Speaker 1: Yeah, you'd never finish. So Okay, the scan runs what
Speaker 1: kind of valuable stuff? What are those gold nuggets? It
Speaker 1: actually finds what are the key takeaways?
Speaker 2: Oh? It's like finding a treasure map to your network's weaknesses.
Speaker 2: It reveals things like unwanted open port stores that shouldn't
Speaker 2: be opened at all.
Speaker 1: Okay.
Speaker 2: It can find default user accounts basically engraved invitations for attackers,
Speaker 2: missing security patches, massive holes, vulnerable software protocols. Sometimes it
Speaker 2: even gives you direct information on how to exploit a vulnerability.
Speaker 2: It's an instant in blueprint of you'rre hidden risks.
Speaker 1: But real world networks they're messy, aren't they? Firewalls, weird configurations.
Speaker 1: The sources mentioned This complexity can lead to false positives.
Speaker 1: What is that exactly?
Speaker 2: Yeah, that's a really important point. A false positive is
Speaker 2: when the scanner reports of vulnerability or maybe says a
Speaker 2: host is live, but it's actually wrong. For example, a
Speaker 2: firewall might just block the scanner's ping, making a machine
Speaker 2: look offline when it's perfectly fine. Understanding these is key
Speaker 2: because chasing down non existent problems waste a ton of time.
Speaker 1: Right, you focus your effort on the real issues. So,
Speaker 1: like any good recipe, you need good prep for the scan.
Speaker 1: What are the key things to get right beforehand?
Speaker 2: Three main things? Really. First, you absolutely have to define
Speaker 2: the scan scope know exactly what you are and aren't scanning,
Speaker 2: and why don't just point it everywhere?
Speaker 1: Okay?
Speaker 2: Scope?
Speaker 1: Second, understand the network architecture. Got a web application firewall?
Speaker 1: You need to know how that affects.
Speaker 2: The scan right, know the landscape. And third, make sure
Speaker 2: the scanner has proper network access. Sometimes you need to
Speaker 2: whitelist its IP address so firewalls don't block its scans.
Speaker 2: You need to clear the path for it.
Speaker 1: Okay, scope, architecture access, got it. But finding the vulnerabilities
Speaker 1: that's just step one. Right. Once you have this list
Speaker 1: of problems, what's next? How do you actually improve security?
Speaker 2: That's why the response and mitigation plan kicks in. It's
Speaker 2: all about fixing what you found, closing those unwanted ports,
Speaker 2: enforcing strong passwords, unique ones, applying the patches you miss,
Speaker 2: maybe disabling old, risky protocols, and crucially remembering network security
Speaker 2: isn't a one off task. It's a continuous cycle. Assess, analyze, mitigate,
Speaker 2: then repeat. You're never really.
Speaker 1: Done right, always iterating. Okay, let's get into the tools themselves.
Speaker 1: First up in the cookbook NESSUS.
Speaker 2: RIGHTSUS, it's a very comprehensive commercial grade vulnerability scanner. Its
Speaker 2: real strength comes from its constantly updated plug in billion. Yeah,
Speaker 2: they're basically little detection scripts. They're written in a language
Speaker 2: called NASL Nessus Attacks Scripting Language. These plugins let nessus
Speaker 2: find new vulnerabilities incredibly quickly, often as soon as they
Speaker 2: become public.
Speaker 1: Wow.
Speaker 2: Plus, it has a nice user friendly web interfhase a GUI,
Speaker 2: which makes setting up and running scans, even complex ones,
Speaker 2: pretty straightforward.
Speaker 1: So it sounds powerful, but how do security teams actually
Speaker 1: use it day to day? What are the practical features
Speaker 1: that make it efficient?
Speaker 2: Missus has several really useful operational features. For example, policies.
Speaker 2: A policy is like a template, a collection of settings
Speaker 2: and scan types you've configured. Ok, you create a policy once,
Speaker 2: say for scanning Windows servers, and then you can reuse
Speaker 2: it for dozens or hundreds of scans. There's a huge
Speaker 2: amount of time I can see that. Then there are
Speaker 2: plugin rules. These let you customize the results. You can
Speaker 2: tell nessus to hide a specific finding or maybe change
Speaker 2: its risk level if you have a compensating control in place.
Speaker 2: Super helpful for managing reports from large scans AH reducing
Speaker 2: noise exactly, and for consultants internal reporting, you can generate
Speaker 2: customized reports, even adding your company logo and tailoring the summaries.
Speaker 1: And what about the basic nessis settings security configuration.
Speaker 2: Yeah, it's built with that in mind. You can set
Speaker 2: a master password to enquip sensitive things like stored credentials.
Speaker 2: You can gifigure proxy servers if NESSAS needs to go
Speaker 2: through under reach the internet or scan targets. Okay, you
Speaker 2: can set up SMTP so it automatically emails you when
Speaker 2: scans are done, and there's robust password management to secure
Speaker 2: the NESSUS console itself. It's pretty why I thought out.
Speaker 1: Okay, NESSUS covered, Let's switch to the other big name,
Speaker 1: end map. What makes nmap the Swiss army knife. Everyone
Speaker 1: calls it.
Speaker 2: Endmap is well tree, It's open source, and it's incredibly versatile.
Speaker 2: It's primarily a command line tool. Its main job is
Speaker 2: to help you map out a network, figure out what
Speaker 2: hosts are up, what ports are open on those hosts,
Speaker 2: and what services are running. It gives you a detailed
Speaker 2: picture of your network's posture and.
Speaker 1: Vers It all seems like an understatement. The options look
Speaker 1: almost endless. You can be really precise or sneaky.
Speaker 2: That's a good way to put it. Take host discovery.
Speaker 2: N MAP can find live systems even if they block
Speaker 2: standard pings. It uses cleverer probes like syn pings, devil
Speaker 2: M pants or azkpings civil p that often slip past
Speaker 2: firewalls that just look for normal ICMP.
Speaker 1: Pings sneaky indeed, and the scanning.
Speaker 2: Itself huge variety and scan techniques. You can choose based
Speaker 2: on speed and stealth. There's the tcpsyn scan SSS. They
Speaker 2: have open scan, which is fast and quiet because it
Speaker 2: doesn't complete the connection, or the full TCP connect scan
Speaker 2: dash ST which is more reliable but noisier, and it
Speaker 2: handles other protocols too, like UDP scans dashes you which
Speaker 2: are important because attackers use UDP too, and you.
Speaker 1: Can tell it exactly which ports to check.
Speaker 2: Absolutely for ports specification by default, and map scans the
Speaker 2: top one thousand most common ports, which is usually a
Speaker 2: good start, but you can tell it to scan a
Speaker 2: specific range like dash EP one sixty five five three
Speaker 2: five for every single port, although that takes time, or
Speaker 2: you can do a fast scan dashes F for just
Speaker 2: the top one hundred ports.
Speaker 1: Super flexible and it doesn't just find open ports, does it. It
Speaker 1: tells you what's running. It's exactly its service and OS
Speaker 1: detection is fantastic. Use the NSSV flag and n MAP
Speaker 1: will try to determine the exact application and version running
Speaker 1: on a port. Use NSO and it'll try to guess
Speaker 1: the operating system of the target machine. Really valuable intel.
Speaker 2: Okay, but here's where NMP gets really interesting. According to
Speaker 2: the sources, evasion and spoofing sounds like spycraft.
Speaker 1: It kind of is. This is where a skilled end
Speaker 1: MAP user can try to bypass network defenses like firewalls
Speaker 1: or intrusion detection systems. Techniques like packet fragmentation. This breaks
Speaker 1: the probe packets into tiny pieces. Some older firewalls struggle
Speaker 1: to reassemble and inspect these fragments properly.
Speaker 2: Clever.
Speaker 1: Or you can use decoy addresses digit D. This makes
Speaker 1: the scan look like it's coming from multiple IP addresses, simultaneously,
Speaker 1: helping to hide your real source IP among the noise.
Speaker 1: You can even spoof your MSc address spoof if the
Speaker 1: network has controls based on physical addresses. It's all about
Speaker 1: being stealthy and making reconnaissance harder to detect or block. So, okay,
Speaker 1: you run these incredibly detailed scans. You get a ton
Speaker 1: of information back. How does NMAP present this? What do
Speaker 1: the outputs look like?
Speaker 2: And map gives you options. It can just print the
Speaker 2: results straight to your terminal screen, which is fine for
Speaker 2: quick scans, yeah, but for saving and analyzing. It has
Speaker 2: several formats. Normal text dash on en is just a
Speaker 2: readable text file xml ox is great because other security
Speaker 2: tools can easily parse and import.
Speaker 1: It right for automation exactly.
Speaker 2: There's also greepable format dash og, which is designed to
Speaker 2: be easily searched with command line tools like GP very
Speaker 2: handy for scripting or quickly finding specific results in large outputs.
Speaker 2: And if you want all three, just USEA and it
Speaker 2: says in all formats at once.
Speaker 1: Convenient and Nessa's, being more of an enterprise tool, probably
Speaker 1: has more formal reporting it does.
Speaker 2: Nessa's supports are generally more power and aimed at different audiences.
Speaker 2: You can export in its own NES's format, which is
Speaker 2: useful for sharing results between different nessas installations. The HTML
Speaker 2: reports are probably the most common output. They're self contained,
Speaker 2: highly detailed, easy to navigate, and usually include an executive summarsection,
Speaker 2: perfect for management who don't need the nitty gritty technical details.
Speaker 2: And you can also export to CSV common separated values,
Speaker 2: which is perfect for pulling the data into spreadsheets for
Speaker 2: further analysis, trending, or customer reporting.
Speaker 1: Okay, this feels like a really critical point, maybe the
Speaker 1: biggest aha moment here confirming vulnerabilities. Why is it so
Speaker 1: absolutely vital to manually double check what these powerful scanners
Speaker 1: tell you?
Speaker 2: Because bottom line scanners make mistakes, They can and do generate.
Speaker 1: False positives, ghost vulnerabilities.
Speaker 2: Exactly, You simply cannot afford to waste time and resources
Speaker 2: fixing problems that don't actually exist. Manually confirming findings is
Speaker 2: about smart resource allocation. It ensures your team is focused
Speaker 2: on fixing real, exploitable threats. It's the crucial step that
Speaker 2: separates automated noise from actionable intelligence.
Speaker 1: Let's make this concrete. The sources had some great real
Speaker 1: world examples. First, a critical risk NESSUS reports a bind
Speaker 1: shell back door.
Speaker 2: Right, so NESSUS flags a specific port, say port one
Speaker 2: teen twenty four on a machine, reporting it allows roots
Speaker 2: shell access with no password needed.
Speaker 1: That sounds really bad, extremely bad.
Speaker 2: So how do you confirm? You could use a simple
Speaker 2: tool like tell net connect to the IP address one
Speaker 2: h two point one six eight point one zero three
Speaker 2: point one two nine on that port one teen twenty four.
Speaker 2: If you get a prompt, type the command d if
Speaker 2: it comes back showing wid zero zero zero root. Well,
Speaker 2: you've just manually confirmed you have root access. It's real
Speaker 2: critical priority.
Speaker 1: Okay, confirmed critical. Next example, a high risk SSL version
Speaker 1: two and three detected old insecure protocols.
Speaker 2: Yeah. NESSUS often flags this because using old SSLTLS versions
Speaker 2: is risky. So it reports say port twenty five typically
Speaker 2: smtpmail is using these out data protocols.
Speaker 1: Sounds plausible, it does.
Speaker 2: But this is where you need to dig deeper. You
Speaker 2: could use n maps script engine, maybe run the ressoblescript
Speaker 2: or sln dom ciphers against that specific port.
Speaker 1: And what might you find?
Speaker 2: This specific case from the source running those end map
Speaker 2: scripts showed no SSL negotiation at all. The port wasn't
Speaker 2: using SSLv two or v three. He wasn't using SSL period.
Speaker 2: It was likely just plain text communication.
Speaker 1: Ah, So Nessa's was wrong.
Speaker 2: Essentially, yes, it was a false positive. It might have
Speaker 2: misinterpreted some banner or response. This completely changes the risk
Speaker 2: picture and highlights why manual verification is non negotiable.
Speaker 1: That's a fantastic example. Okay, one more medium risk Apache
Speaker 1: Tomcat default files found.
Speaker 2: This one's simpler. Nessa's points out that default documentation or
Speaker 2: example files are accessible on a Tomcat web server, maybe
Speaker 2: on port A one eighty. How to check easiest way
Speaker 2: just open your web browser and go to the url
Speaker 2: Nessus indicated something like http dot one nine to two
Speaker 2: point one sixty eight point one zero three point one
Speaker 2: two nine point eight one eight zero tomcat dot com html.
Speaker 2: If the default Tomcat documentation page loads up without asking
Speaker 2: for a password, then yes, the finding is concerned. A
Speaker 2: medium risk needs cleaning up.
Speaker 1: These examples really show it's not just about running the tool.
Speaker 1: It's about the analyst using the tool's output as a
Speaker 1: starting point, then applying critical thinking to confirm what's real
Speaker 1: and what's not.
Speaker 2: Couldn't agree more. The real power isn't just the scanner.
Speaker 2: It's the combination of the scanner and an informed analyst.
Speaker 2: And speaking of power, both tools offer great ways to
Speaker 2: customize them even further, let's talk about an end map
Speaker 2: script engine NSE. Right.
Speaker 1: NSE you mentioned it for a discovery It lets users
Speaker 1: write their own scripts in LUA. Right, what kind of
Speaker 1: things can you do with that?
Speaker 2: NSESE really extends endmap way beyond basic port scanning. You
Speaker 2: can write scripts for almost anything network related, more sophisticated
Speaker 2: host discovery, detecting very specific or unusual services, checking for
Speaker 2: specific vulnerabilities that maybe aren't in the main databases yet,
Speaker 2: even performing basic authentication checks, or in some cases safely
Speaker 2: testing exploits. Wow. These scripts fall into categories like auth discovery,
Speaker 2: VULN exploit, and writing a basic one isn't super complex.
Speaker 2: They have a standard structure, a head part with info
Speaker 2: about the script, a rule part saying when it should run,
Speaker 2: and an action part saying what it should do.
Speaker 1: So, like that Tomcat example, you could write a specific
Speaker 1: ns script just to check for those default files exactly.
Speaker 2: Instead of relying on a broad vulnerability scan, you could
Speaker 2: have a targeted NSE script that does just that one
Speaker 2: check very efficiently. It's incredibly powerful for tailoring and MAAP
Speaker 2: to your specific needs.
Speaker 1: And Nessa says customization too, especially around compliance and auditing.
Speaker 2: Yes, particularly with its audit policies. These use custom XML
Speaker 2: based files, often called dot audit files. These files contain
Speaker 2: rules that compare the actual configuration of a system, say
Speaker 2: settings in the operating system or an application against a
Speaker 2: predefined security baseliner.
Speaker 1: Standard like CIS benchmarks.
Speaker 2: Precisely things like CIS benchmarks, decist eggs, or even hypo requirements.
Speaker 2: This is essential for white box assessments where you have
Speaker 2: credentials to log into the system and check its internal
Speaker 2: configuration thoroughly. You can even write your own custom checks
Speaker 2: in XML for company specific policies. It moves beyond just
Speaker 2: network vulnerabilities into configuration hardening and compliance.
Speaker 1: Okay, this is all fascinating for standard IT networks, but
Speaker 1: let's shift focus to something even more critical. Scanning industrial
Speaker 1: control systems, IoT devices, the operational technology or OT world.
Speaker 2: Ah, Yes, OT and ICs. This is where network security
Speaker 2: gets well potentially kinetic. We're talking about the systems that
Speaker 2: manage physical industrial processes, power generation, manufacturing lines, water treatment plants, building, automation,
Speaker 2: and the list goes on. Industrial control systems ICs are
Speaker 2: the heart of it.
Speaker 1: And SCATI fits in here too. Yes.
Speaker 2: Scatter supervisory control and data acquisition systems are often used
Speaker 2: to provide that remote monitoring and control interface for ICs environments.
Speaker 2: They're designed for high availability keeping processes running.
Speaker 1: The risk here seems enormous. A failure isn't just data loss,
Speaker 1: it could be much worse.
Speaker 2: Exactly, A misconfiguration or exploited vulnerability in a SCATA or
Speaker 2: ICs system could have catastrophic physical consequences and complicating matters.
Speaker 2: Many of these systems are old. They were designed decades ago,
Speaker 2: long before cybersecurity was a major concern, so they can
Speaker 2: be incredibly fragile and full of vulnerabilities.
Speaker 1: So can you even use tools like enmap and NESSUS
Speaker 1: on these systems safely? It sounds risky.
Speaker 2: You can, but you have to be extremely careful and knowledgeable.
Speaker 2: In Map, for instance, has specific NSE scripts designed for
Speaker 2: common ICs protocols. There's S seven dash info dot NZA
Speaker 2: for Siemens S seven controllers and Modbus Dash Discover dot
Speaker 2: NSA for modbus devices. These are widely used. They usually
Speaker 2: talk on specific ports like TCP Port one oh two
Speaker 2: for Semens S seven and port five oh two for Modbus.
Speaker 2: NMAP can identify these systems and ness's nessis also has
Speaker 2: dedicated plug in families specifically for SCATA and ICs devices. But,
Speaker 2: and this is critical, you must configure NESSUS very carefully.
Speaker 2: There's often an option like performed thorough tests or similar
Speaker 2: unsafe checks. You absolutely want to make sure those dangerous
Speaker 2: options are disabled when scanning sensitive ICs environments to avoid
Speaker 2: crashing PLCs or disrupting critical processes.
Speaker 1: That distinction is absolutely vital. Don't break the power plant
Speaker 1: while trying to secure.
Speaker 2: It, please don't. It really underscores that understanding these tools
Speaker 2: isn't just about corporate IT security anymore. It's about the
Speaker 2: broader security of our physical infrastructure too.
Speaker 1: Right, and once you find these vulnerabilities, other tools might
Speaker 1: come into play.
Speaker 2: Unfortunately, Yes, frameworks like Metasploid also contained modules specifically designed
Speaker 2: to exploit known SCATA and ICs vulnerabilities. It highlights the
Speaker 2: urgent need for proactive discovery and careful mitigation in these
Speaker 2: critical environments.
Speaker 1: So we've really taken a deep dive today. We've gone
Speaker 1: through the practical world of network security scanning, looked closely
Speaker 1: at ENMP and NESSUS. Hopefully you listening now have a
Speaker 1: much better grasp of not just what they do, but
Speaker 1: why they do it, how to read their outputs, and crucially,
Speaker 1: how to apply that critical thinking to confirm what really matters.
Speaker 2: And remember it's not a one and done thing. Network
Speaker 2: security is absolutely a continuous cycle. Assess analyze, mitigate, and
Speaker 2: then start again constant vigilance.
Speaker 1: So here's a final thought to leave you with. In
Speaker 1: a world where everything, even our critical industrial systems, is
Speaker 1: connected and potentially vulnerable, how does really understanding these deep
Speaker 1: dive scanning techniques empower you not just to protect networks,
Speaker 1: but to critically evaluate all the security information you encounter
Speaker 1: and ultimately become a more informed guardian of both our
Speaker 1: digital and our physical world.