Stay Ahead With Linux Security Features
threat detection scalability Building a SIEM is easier than scaling one. Most open-source deployments start as a simple "all-in-one" server. It is easy to set up, but that design rarely survives the transition from a lab to a production workload. . A SIEM watching 20 endpoints is not doing the same job as one watching 500. More endpoints mean more logs; more logs require more storage; more storage makes search heavier. Eventually, the very architecture that made your lab easy to deploy becomes the reason your production...
Jun 04, 2026
security advisory apache A newly disclosed attack technique called HTTP/2 Bomb is drawing attention because it targets the software that sits at the front of much of the Linux internet. Apache HTTP Server, NGINX, Envoy, and the ingress layers that many Kubernetes environments depend on can be forced into consuming disproportionate amounts of memory using relatively small amounts of attacker traffic. . For Linux administrators, the concern is not the HTTP/2 protocol itself. It is the possibility that a single...
Jun 04, 2026
security advisory important The compromise of Nx Console shows how much infrastructure now sits behind a single developer account. GitHub repositories, CI/CD pipelines, container build systems, Terraform projects, Kubernetes deployments. None of those systems was the initial target. The workstation was. . Attackers did not need a Linux privilege escalation bug or a remote code execution chain. They needed developers to trust a tool they were already using. For many organizations, that was enough. What Happened? Federal...
Jun 03, 2026
security advisory open-source You remove the malware. You rotate the compromised credentials. You patch the original vulnerability and close the ticket. Two weeks later, the attacker is back. . What happened? You didn't lose the battle at the exploit; you lost it at the cleanup. In many modern Linux intrusions, the malware you found wasn't the main problem—it was the fallback mechanisms left behind. These hooks quietly restore attacker access the moment you look away. If you clean a host but miss these persistence layers,...
Jun 02, 2026
security advisory Red Hat Researchers investigating a campaign now tracked as Miasma found that more than 30 packages in Red Hat's @redhat-cloud-services npm namespace had been altered to deliver credential-stealing malware. . The packages weren't being used to deploy ransomware or sabotage systems. From what has been reported so far, the objective appears to have been much simpler: collect credentials from developer environments and use that access elsewhere. GitHub tokens, cloud credentials, SSH keys, and other...
Jun 02, 2026
Refine features
X Clear Filters
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Loading...
Explore Latest Linux Security features
We found 2 articles for you...
102
network monitoringthreat detectionsecurity technologyUnderstanding Intrusion Detection Systems
Modern networks generate more traffic than most teams can realistically watch. Internal services talk constantly, cloud workloads spin up and down, and even well-configured defenses don’t stop every attack. Stolen credentials still get used. Misconfigured services sit exposed longer than anyone expects. Sooner or later, something slips through, and the first sign usually shows up in the logs. Intrusion detection systems help surface that activity, giving administrators and analysts visibility into connections, authentication attempts, and network behavior that deserves a closer look.. What Is an Intrusion Detection System? An intrusion detection system (IDS) monitors network or system activity to identify suspicious behavior, policy violations, or patterns associated with known attacks. It doesn’t block traffic or shut connections down. Intrusion detection systems watch what is happening across the environment and generate alerts when activity starts to resemble techniques security teams have learned to recognize over time. Most deployments end up tracking connection attempts, authentication activity, protocol behavior, and traffic patterns moving between hosts. The system compares those events against known attack signatures and traffic patterns seen during common intrusion activity. When a match appears, the IDS logs the event and generates an alert so someone can review the connection and the host involved. What that alert means still has to be figured out. Sometimes it’s a misconfigured service hammering another host with retries. Sometimes it’s an automated scan moving across the network looking for exposed services. And sometimes it’s the early stage of an intrusion, which is where the investigation moves into the broader process of intrusion detection response . How Do Intrusion Detection Systems Detect Threats? Intrusion detection systems detect threats by watching network traffic and system activity for patterns that shouldn’t be there. In most environments, workhappens inside network sensors inspecting packets, track connections, and record events as traffic moves between hosts. After reviewing enough alerts, certain signals start repeating. Some are tied to known exploits. Others just look wrong compared to the rest of the network that day. That’s why IDS platforms usually rely on several detection approaches at the same time. Signature-based detection This is the most familiar approach. The IDS compares packets and events against a library of known attack signatures. When traffic matches one of those patterns, the system logs the event and raises an alert. It works well for exploits that have already been documented, although signatures have to stay current or new techniques slip past unnoticed. Anomaly detection Some activity doesn’t match a signature at all. Instead, it stands out because it behaves differently from the rest of the environment. A server is suddenly pushing far more data than usual. Authentication attempts appear at odd hours. Systems that normally never talk to each other. Those shifts can reveal attacks that rule-based detection never catches. Behavioral monitoring Intrusions rarely appear as a single event. They show up as a sequence. A login attempt appears, then another. Eventually, one succeeds. A few minutes later that host begins reaching out to internal systems it has never contacted before. Each step alone might look ordinary. Together, they start to tell a different story. Traditional detection still has limits. Encryption hides packet contents, attackers change techniques constantly, and large networks generate more alerts than analysts can realistically review. That’s why newer detection models increasingly rely on behavioral analysis and traffic patterns, an approach explored further in modern IDS approaches . What Is the Difference Between IDS and IPS? The difference between intrusion detection and prevention systems comes down to visibility versus enforcement. Anintrusion detection system monitors network traffic and raises alerts when activity looks suspicious, while an intrusion prevention system sits inline and can block that traffic when a rule triggers. That placement changes how the systems behave on a real network. IDS watches connections, logs events, and surfaces activity that deserves investigation. IPS becomes part of the traffic path itself, so when a rule fires, the system can interrupt the connection or terminate the session. The operational tradeoffs between detection and prevention are explored further in IDS vs IPS . Detection keeps the network untouched while giving teams visibility into suspicious activity. Prevention introduces control, and with that control comes responsibility for the decisions the system makes. False positives make the difference obvious. An IDS alert appears for review. An IPS rule can interrupt application traffic or block legitimate users if the system reacts too aggressively. What Happens After an IDS Detects Suspicious Activity? After an intrusion detection system flags suspicious activity, the process moves into intrusion detection response. Detection surfaces the event, logs it, and generates an alert. Most environments end up working through roughly the same sequence. Alert generation: The IDS records the rule match and produces an alert describing the connection, host, or traffic pattern that triggered detection. Initial review: Someone looks at the alert details first. That usually means checking surrounding logs, connection history, and related system activity. Investigation: If the activity still looks suspicious, the analysis goes deeper. The question becomes whether the behavior reflects reconnaissance, credential abuse, or something mundane like a misconfigured service retrying requests. Response decision: Only after that context is understood does an actual response decision take place. The real work is figuring out whether the alert reflects a genuine intrusionattempt or something routine that simply looks unusual. Alerts rarely explain the situation on their own. A connection pattern might indicate scanning activity, repeated authentication attempts, or a system behaving unexpectedly. The surrounding context is what determines which one it is. Response also introduces operational risk. Acting too quickly can disrupt legitimate services, while waiting too long can allow an attacker more time inside the environment, which is why the investigation stage naturally leads into intrusion detection response once analysts understand what the alert actually represents. How Do Most Organizations Measure IDS Effectiveness? Organizations measure IDS effectiveness through IDS performance testing and intrusion detection system metrics that show whether the system can inspect real network traffic without missing suspicious activity. In practice, this becomes a balance between traffic volume, inspection depth, and the quality of alerts analysts receive. Throughput: How much traffic the IDS can process before packets begin slipping past inspection. High-traffic environments quickly expose the limits of a detection sensor. Latency: Inspection takes time. If analysis adds too much delay, it can affect application performance or create bottlenecks in busy network segments. Packet inspection capacity: IDS sensors track sessions, parse protocols, and apply detection rules at the same time. The question becomes how much traffic the system can fully inspect without losing visibility. Detection accuracy: Alerts need to reflect real attack activity. Systems that miss known attack patterns or misidentify normal traffic create gaps in monitoring. Alert noise: Review enough alerts, and you’ll notice how quickly unnecessary ones add up. When analysts spend most of their time filtering harmless events, real intrusion attempts become harder to spot. These measurements usually come from IDS performance testing , where teams observe how detectionsystems behave under real network conditions and traffic loads. How Are Intrusion Detection Systems Deployed? Intrusion detection systems are usually deployed by placing sensors where they can observe meaningful network traffic. The goal is visibility. If the system cannot see the traffic where authentication, service connections, or lateral movement occur, it cannot detect much. Most deployments end up coming down to a few practical decisions: Sensor placement: Sensors are positioned where traffic converges. Network boundaries, internal segments that host sensitive systems, or shared infrastructure where many connections pass through. Network visibility: The IDS needs access to traffic streams where authentication attempts, service connections, and data movement occur. Without that visibility, the system simply never sees the activity it is supposed to detect. Integration with monitoring systems: IDS alerts rarely stand alone. Most deployments feed event data into security monitoring platforms so analysts can review IDS alerts alongside logs and other network activity. Many intrusion detection tools exist, but Snort intrusion detection is often used as the reference example because it clearly demonstrates how rule-based network detection works in practice. How Does Snort Detect Network Intrusions? Snort detects network intrusions by inspecting packets moving across the network and evaluating them against detection rules that identify suspicious traffic patterns. As one of the most widely used intrusion detection tools, Snort focuses on analyzing traffic behavior as it moves between systems. Packet inspection Snort analyzes packets as they move through the network, examining headers, payload data, and session information. Rule evaluation Traffic is compared against detection rules describing known attack behavior or suspicious packet patterns. Protocol analysis The system evaluates whether protocols behave as expected during communication.Malformed packets, unusual requests, or protocol abuse can signal exploitation attempts. When one of these checks identifies suspicious activity, Snort records the event and generates an alert so analysts can review what the system observed. Many teams first encounter these detection techniques when working with tools like Snort. Our guide on network intrusion detection using Snort walks through how packet inspection, rule evaluation, and protocol analysis surface suspicious traffic. How Are IDS Alerts Used in Security Operations? IDS alerts surface suspicious activity so security teams can investigate what is happening on the network. Through IDS alerting, detection systems generate events that feed into broader security monitoring workflows. Most alerts move through a simple operational pipeline. First, the detection system generates an alert when traffic matches a rule or suspicious pattern. The event is then recorded so analysts can review it alongside other network activity. From there, the alert becomes part of ongoing security monitoring, where patterns across systems and time begin to emerge. Seen once, an alert might not mean much. Seen repeatedly across different hosts, it starts to look like reconnaissance or credential probing. When alerts arrive quickly, the sequence becomes easier to understand. Real-time IDS alerting helps analysts watch suspicious activity develop instead of reconstructing it afterward. Are Intrusion Detection Systems Enough to Secure a Server? Intrusion detection systems help monitor server activity, but they are not enough on their own to secure a system. IDS identifies suspicious behavior on the network. It does not confirm whether the system itself remains secure. What IDS does Observes network activity Flags suspicious connections or authentication attempts Generates alerts when behavior matches known attack patterns What other controls handle Verifying system configuration and software integrity Confirmingthat permissions and services remain secure Checking whether recent changes introduced a new risk Detection tells you when something unusual might be happening. Determining whether the system itself is still trustworthy usually involves taking time to verify Linux server security during regular security checks. . Explore the realm of Intrusion Detection Systems (IDS), examining their various forms and significance for safeguarding networks in the contemporary digital environment.. Intrusion Detection Systems, Cybersecurity, Host Monitoring, Network Traffic, Security Infrastructure. . Mak Ulac
Feb 16, 2026
•
102
data securitynetwork monitoringcloud securityEnhance Linux Network Security with ManageEngine OpManager
Businesses must digitize their services to provide clients and end users with data and network security while ensuring they have no web application security vulnerabilities that could interfere with the company's reputation and credibility. Linux and Windows serve as bases for most business networks today, and more rely on Linux due to its effective and efficient scalability, security, customization, consistency, and flexibility. . Linux-based networks require a monitoring tool to maintain device inventory, give real-time status updates, spot traffic congestion across interfaces, and provide insightful reports regarding system performance. ManageEngine OpManager has a holistic, dynamic nature permits it to strengthen data and network security and address any Linux patches a server needs. This article will discuss the various features of OpManager, so you understand the benefits of the service. What is OpManager: The Powerful Linux Monitoring Tool? The ManageEngine OpManager is a potent monitoring tool that scrutinizes all Linux network security threats on Linux-based devices to mitigate constantly rising performance and bandwidth network security issues. OpManager’s Linux monitor has various aspects to its cloud security framework: Intuitive discovery: Maintain network inventory of Linux-based systems Real-time monitoring: Gain instant device status updates Fault management: Manage network security risks efficiently Advanced Reporting: Oversee network performance of Linux-based devices Let’s review these parts of OpManager in further detail so you better understand how they bolster data and network security and Linux security patching appropriately. Intuitive Linux Device Discovery OpManager has a “Scheduled Discovery” feature that runs automated cloud security scanners to find changes in the network. This tool can add and configure devices and permissions, so you do not need to manually, which is time-consuming and often challenging. These automatic updatespermit companies to focus on other tasks within their daily operations. OpManager's Linux device templates and Discovery Rule Engines can automate the association of performance monitors with these discovered devices. Real-time Linux Network and Server Monitoring Your Linux-based devices and servers require healthy data and network security to perform at their best. OpManager can monitor your systems in real-time to notify you of any outages impacting network performance, end-user experience, and business reputation. Linux monitoring is a reliable way to thwart performance and network security issues while retaining control of your system. Linux Network Traffic Monitoring Leverage OpManager to track traffic flow, identify network congestion, and mitigate any network security issues the server might encounter. Monitoring the system can improve security posture, assist you in IO request management, and ensure that Linux operations continue uninterrupted. Oversee network traffic in Linux interfaces among servers, switches, and routers so you can track the servers' response time and identify and fix network lags before they affect end users. Fault Management for Linux Devices OpManager uses active alerting in fault management to automate L1 and L2 troubleshooting tasks. L1s are troubleshooting engineers, and L2s receive and analyze troubleshooting tickets to prepare companies if needed. Here are a couple of the specific features of OpManager’s fault management services: Active Alerting OpManager utilizes different Linux network monitoring tools to alert for various cloud security breaches that could take place. These alarms include “Attention,” “Trouble,” and “Critical” and are based on the severity of the issue so that you understand how quickly you must react to the network security threat. With active alerting, you can prioritize Linux security patching and troubleshoot network security issues that require immediate attention. Configure these alarms toescalate or alternate to other employees if previous recipients do not see the notification in due time, preventing critical faults that will impact network performance. Intelligent Automations On-field teams sometimes rush to a situation only to learn they could have done the troubleshooting remotely. Other times, network admins will perform routine maintenance, and while they are necessary for ensuring Linux network health, the tasks are repetitive and time-consuming, IT security professionals must understand how automation can save significant time and effort, and OpManager’s Workflows helps companies do just that. Workflows automate L1 and L2 troubleshooting tasks that do not need manual intervention so that all you have to do is define the action required and its criteria. Once you drag and drop the desired Linux devices into the Workflows feature, you can focus on other critical tasks while the service automates those specific ones. Advanced Reporting OpManager helps countless organizations stay secure and resourceful while analyzing historical data to understand your server's latest data and network security trends and growth patterns. Reports of network health, availability, hardware metrics, application performance, and more permit this cloud security framework to forecast any network security issues within your CPU. Plan your storage capacity so you can upgrade and avoid potential CPU and memory risks that could harm your server. Built-In Linux Troubleshooting Tools OpManager's Linux monitoring has a built-in network security toolkit that aids in quicker Linux network security threat troubleshooting. Here are the ones to know: Ping Tool Traceroute CLI Tool SNMP Tool MAC Address Resolver DNS Resolver DHCP Scope Monitor Port Scanner Final Thoughts on Managing Your Linux Network Efficiently & Securely OpManager's Linux monitoring helps you effectively discover, classify, and track Linux network devices across 10,000 device types, 450 device vendors, and30,000 network devices out-of-the-box. Visualize business-critical Linux appliances and traffic in real-time with OpManager’s Business Views. OpManager alerts you instantly of any performance outages through various notification channels such as SMS, email, ticket logs, and web alarms. This comprehensive monitoring helps simplify Linux services and prepares you for future data and network security issues. . Oversee Linux systems using sophisticated utilities to boost protection, maintain efficiency, and address vulnerabilities strategically.. Network Security, Linux Management, Performance Monitoring, Data Protection. . Anthony Pell
Oct 09, 2023
•
102
security practicesnetwork monitoringsoftware managementCommon Sysadmin Mistakes and Best Practices for Network Security
It is valuable to learn from any administrative mistakes you make rather than repeat the same issue again. System administrators, or sysadmins, make mistakes but utilize what they learn to develop more skills, advance their careers, and improve their capabilities. It's also helpful to learn from the blunders of others, so today, we will discuss ten common administrative mistakes sysadmins make and how to address such problems. . Overuse of Privilege Escalation Sudo access permits users to control who runs commands on the system, as well as permits such users to do so with elevated privileges. Sysadmins can delegate permissions so workers can perform certain root commands and provide an audit record of actions and arguments. Adversaries can escalate privileges by implementing poorly configured methods that take away the need for a password. It's easy for sysadmins to get frustrated every time workers require sudo access for a minor task, so rather than finding an alternative, a system administrator will grant permanent sudo access to specific programs for users. This gives workers a clear path to the root software so they can utilize interactive shells and write to file systems. However, these types of common administrative mistakes give threat actors more advantage should they be able to breach into a sudo-accessed area of a system. A mitigation solution would be to implement privileged account management. Even if an attacker has terminal access, they must know the password to run anything in sudo-accessed files. Sysadmins can also restrict file and directory permissions by modifying files to require passwords so users with greater privileges cannot initiate dangerous processes. Key Takeaways: Use privilege account management. Restrict files and directories. Avoid using sudo if you don't have to. Use of Outdated Software Many of us are guilty of postponing a software update. As a system administrator, this laziness can be detrimental to your organization.It is critical that sysadmins track security advisories and network security issues and install security updates as soon as they become available. Many servers have been affected because a year-old fix was never installed, and instead, these servers were compromised by a zero-day attack. Cybersecurity vulnerabilities can result from a lack of proper security patching done in due time. Hackers can sometimes see the updated patches and use them to instigate attacks in network security for systems that haven't upgraded yet. Missing updates might not always be due to mismanagement but could be because it would damage a legacy app. If it's a crucial server, a few minutes of downtime during a scheduled maintenance window is preferable to losing hours or days because the box has been effectively compromised due to a network security threat. Test patches as soon as they are issued and set up a schedule for releasing updates. Perhaps there are ways to quarantine the servers to limit risk or to adopt new technologies to lessen reliance on legacy services. Security patching can be a political minefield in real life. If a higher-ranking manager prohibits a system from being patched, make sure everyone understands the consequences of not doing so. Bring the issue to the attention of the proper stakeholders and management so that everyone works to mitigate such cyber security vulnerabilities and avoids making such common administrative mistakes. Key Takeaways: Test patches as soon as they are available. Quarantine servers if you can't push a crucial update. Make sure that management understands the importance of the update. Bad Password Management Although passwords are still one of the most secure ways of authentication available, they are one of various cyber security vulnerabilities at risk when misused . Password management is helpful in this situation, as it is a collection of guidelines to follow while saving and managing passwords to keep systems as secure as possible and preventunwanted access that could result in network security issues. Servers are frequently set up with weak administrator credentials or the same password for other machines. Because many people still make this basic mistake, brute-force attacks utilizing common passwords work. This network security threat becomes much worse when numerous machines share the same password, making it one of these common administrative mistakes. Sysadmins should utilize a key file instead of using the same root password on all computers. Each server should have a public key file, and the private key should be paired with the public key on the system admin's desktop. Key Takeaways: Don't use the same root password on all machines. Use a key file instead. Make sure admin credentials are strong. Do not have a list of passwords stored in a text file. Troubleshooting Incorrect VLAN Assignment Sysadmins use Virtual Local Area Networks (VLANs) to segment and organize networks. Segmenting has several benefits, including greater security since devices can only connect with other VLAN systems, as those are the only ones visible to users. VLANs can aid in controlling broadcast traffic and the movement of end systems around a network. Users will be sent to the wrong VLAN if not correctly configured in these common administrative mistakes. This is why sysadmins have to deal with difficulties like network devices being unable to connect to switch ports, failed device registration efforts, and the inability to connect the device to critical servers. To ensure that the device has the right IP address, test the switch port. Check which VLAN is configured on that port using a VLAN tag and make the necessary modifications. With documentation, you can avoid having cybersecurity vulnerabilities within your VLAN settings. VLAN is frequently assigned to the wrong port due to a lack of communication. Sysadmins, for example, would never know that specific ports need to be adjusted to be compatible with new services if therewas no documentation. Key Takeaways: Reconfigure ports to support new services. Check switch configuration to validate new VLAN assignments. Test the port to see which VLANs are supported. Monitoring Log Files for Tampering and Attack Signals Log files keep track of what's going on behind the scenes, so if something goes wrong with a complex system, you can refer to a complete record of events that occurred before the failure. This record includes transactions, errors, and intrusions. An Advanced Persistent Threat (APT) in your organization or other attacks in network security could result in your log files, typically in the form of transaction issues. Sysadmins keeping track of log files can increase the chance of catching and stopping an intruder before any severe damage can occur. Log filtering software can help you analyze the data and find relevant log messages to prevent persisting common administrative mistakes. Key Takeaways: Write logs to two separate locations and compare hashes. Don't log passwords or failed passwords from logins. Use log-filtering software to help find relevant information. IP Address Conflict At any one time, one IP address is assigned to each device on a network by default. However, two devices sharing the same IP address can prevent users from connecting to a network. The default Dynamic Host Configuration Protocol (DHCP) configuration on your router could be to blame, as well as manual human error. Having a good DHCP server on your network is critical to protect your devices from IP conflicts. Bad DHCP servers may contain cyber security vulnerabilities that cause IP conflicts by incorrectly assigning IP addresses to network devices during dynamic IP allocation. Sysadmins should reconfigure the router to assign DHCP addresses to the top end of your subnet, leaving the static IP addresses out of the mix to avoid these common administrative mistakes. Key Takeaways: Check IP conflicts that arise from DHCP servers. Check BYOD policies. Release and renew your IP address. Preventing DNS Failures The Domain Name System (DNS) is a decentralized and hierarchical naming system for identifying computers, services, and other resources accessible via the Internet or Internet Protocol networks. DNS failure prevents users from accessing the internet and other critical applications. A failed connection request occurs when the client PC cannot resolve the server name with the server's IP address. Cache poisoning, DDoS, and DNS rebinding attacks in network security are some exploits that adversaries might use to induce DNS failure. Workstations may be configured to use their DNS server for highly active networks, resulting in a DNS traversal to your ISP's servers and overloading the router. To directly access their DNS servers, sysadmins need to change the client's DHCP settings. Disable DNS recursion to prevent DNS poisoning attacks. Have a server that will activate in the event of the nameservers failure to ensure data and network security. Key Takeaways: Properly configure DHCP settings. Be prepared with a DNS failover. Disable DNS recursion to prevent cache poisoning. Not Using Security Audits Best Practices A security audit is a thorough examination of your company's information system. Often, this examination compares the security of your system to a checklist of industry best practices, externally defined standards, or federal regulations. The audit thoroughly examines all aspects of your IT infrastructure, including operating systems, servers, digital communication and sharing abilities, network security toolkits, apps, and data storage and gathering methods. A security audit will give a roadmap of your organization's primary information cyber security vulnerabilities, identifying where it is meeting and where it is not fulfilling the requirements set forth by the organization. For firms that deal with individuals' sensitive and confidential data, security audits are essentialfor building risk assessment plans and mitigation measures. On the market, there are a variety of Computer-Assisted Audit Techniques (CAATs) that can help sysadmins automate the audit process to help with common administrative mistakes. CAATs go through the processes of an audit regularly, looking for cybersecurity vulnerabilities and generating audit reports automatically. Key Takeaways: Understand that audits are essential for security. Enlist a third-party auditor. Use CAATs to automate the audit process. Poor SSH Key Management SSH is a secure protocol commonly used to connect to Linux servers. By establishing a remote shell, it provides a text-based interface. All commands you enter in your terminal are transferred to the remote server and executed after you connect. Any commands you type into your terminal are transferred across an encrypted SSH tunnel and executed on your server for the length of your SSH session. SSH is used by sysadmins frequently alongside SSH keys. Mismanagement of SSH keys exposes you to data and network security threats and puts you out of compliance with industry regulations. If your keys are lying around or you frequently hand them out to everyone, that's very bad for security. Having an improper key management setup could also affect compliance needs. SSH key management is a set of network security toolkits, policies, and processes that enable sysadmins to safeguard and manage such digital key pairs to prevent future common administrative mistakes. Users can utilize secure shell keys to authenticate themselves to your network, servers, or other systems and securely transfer files without logging in every time. Key Takeaways: Keep an eye on the SSH key rotation. SSH keys should be tied to a specific person rather than an account several people can access. Find and keep an inventory of all SSH keys. Improperly Configured & Open Ports Ports allow devices to communicate with one another. To perform their tasks, internet-facingservices, and applications listen on ports for a connection from the outside. Communication between hosts via the internet is impossible wi thout ports. One of the most common administrative mistakes takes place when a port is left open when it should be closed. An administrator may have opened a port to fulfill a request and then forgotten about it, or a program may have automatically changed a firewall configuration, leaving some ports open without your knowledge. Ports that aren't absolutely necessary should be closed as soon as possible to mitigate this network security threat. Sysadmins can also run port scans with network security toolkits like Nmap regularly. Key Takeaways: Check for open ports with vulnerability scanners. After opening a port for requests, remember to close them. Check for ports that may have been opened from the firewall configuration. Final Thoughts on Avoiding Common Administrative Mistakes as Sysadmins Learning from others' mistakes can also be an invaluable tool to grow as a sysadmin without compromising company security in the process. In this article, we looked at ten common administrative mistakes that sysadmins make regarding security and tips for avoiding these pitfalls. We encourage you to explore this LinuxSecurity must-read article on top tips for securing your Linux system so that you can better protect your company against any and all cybersecurity vulnerabilities. A common oversight by sysadmins involves underestimating the significance of a robust secure remote access solution . Thus, it is crucial to integrate a dependable remote access system which safeguards against unauthorized entries and counteracts potential threats from remote links, essential measures for ensuring network security. Have you made any of these mistakes, or do you have additional advice for avoiding these issues? We'd love to discuss this with you! . Explore common sysadmin pitfalls and preventative measures to enhance network security and operationalpractices effectively.. Sysadmin Mistakes, Network Security Practices, Security Audits, Password Management, Software Updates. . James Bogert
Aug 01, 2023
•
102
network monitoringopen sourceIT infrastructureTop Open Source Network Monitoring Tools For IT Infrastructure Management
It's necessary to monitor your company's network for several reasons. Modern networks can be monitored in a variety of ways. In contrast to application performance management systems, which use agents to retrieve performance information from the application stack, network monitoring tools are specifically made for the purpose of monitoring network traffic and response times. . Regardless of the sector you operate in, you must install some sort of network monitoring if your company relies on a network to function. Linux network monitoring solutions are a priceless resource that gives you the visibility you need to maintain your system's operation. The performance of individual nodes and apps can be monitored using Linux network monitoring solutions. This article provides an overview of Linux network monitoring solutions that can be deployed. Why Are Network Monitoring Tools Important? Linux network monitoring solutions are essential for maintaining networks since they let you monitor all connected devices from a single location. By identifying devices with poor performance, these tools make it easier for you to intervene and troubleshoot the problem at the source. Executing thorough troubleshooting can reduce performance issues and guard against security vulnerabilities. Another benefit of routine network maintenance is preventing disruptions that could send thousands of customers offline. Using a network monitoring tool, you can: Auto-discover connected devices View real-time and past performance data for devices and apps. Set up alerts to notify unusual activities. Analyze network activity through graphs and reports Benefits Of Open Source Monitoring Open-source server monitoring comes with features that keep track of logs and monitor shared server data to improve security. Users of these programs can email service request responses and crash reports. These open-source monitors can also scan the entire server, checking each line of code and piece of data forflaws and making recommendations for how to solve them. Some other benefits include the following: Cost-effective: Most open-source software can be used free of cost. A small expense may be incurred when third-party products, such as plug-ins, are used. However, open-source software is free for anybody to download and use any way they see fit. Flexible: Open-source software is designed with the premise that it can and will be upgraded as users discover bugs and areas for development. Users can patch a bug and upload the program's revised version if they discover a bug. You can continue utilizing the same tools you have been using with open source and add new features as required. Secure: Because open-source code is publicly available and editable, anyone can review it and fix errors. Thus, open-source software has the potential to be highly secure . Top 5 Open Source Network Monitoring Tools Open-source Linux network monitoring solutions that suit your needs are usually influenced by several elements, such as auto-discovery, data mapping, event logging, alarm systems, reporting, and server request management. However, to make your experience better, here is a guide to open source monitoring tools that are considered to be industry leaders by experts. Cacti Cacti is a graphing tool that works as an add-on to RRDTool and is used by many network managers to gather performance information in LANs. To build graphs of traffic data, Cacti supports the Simple Network Management Protocol (SNMP) on Windows and Linux. Data used by Cacti typically comes from user-written programs that ping hosts on a network. Graphs are created using the values that the scripts produced, which are stored in a MySQL database. Depending on the needs, Cacti can additionally customize the servers and dashboard. Cacti also allows users to set a timer for polling and will automatically generate graphs from the gathered data of each poll. Another one of its capabilities is that as a devicemonitoring tool it can automatically scan for and add new devices once they are found. One of Cacti’s available plugins is called Spine and it allows for faster polling, which can especially be helpful for users monitoring larger networks. Cacti also supports users, user groups, and domains, allowing administrators to set different permissions based on only what they need and therefore not risking or compromising the network. Moreover, Cacti is a customizable tool that offers a variety of themes, skins, and languages, as well as around 12 plugins. You can download Cacti here. Nagios As an open-source monitoring system, Nagios provides various features, including the ability to integrate external applications by utilizing an additional plugin. Applications, websites, middleware, and web servers are just a few of the many settings that it can monitor. Additionally, this application includes a problem-response technique that allows you to address website issues and expedite work. With Windows monitoring built in, this tool enables users to manage statistics and retrieve information from the website. A huge volume of requests can be readily handled by Linux monitoring with Linux servers. The application monitoring capability aids in managing traffic coming from the application and extracting data from it. It also has a quick page-fixing detection technology. Nagios uses server-client architecture and operates with MSSQL for data. It can monitor and generate graphs on operating system metrics, services, state as well as a variety of different protocols including SMTP, POP3, HTTPS, and more. Furthermore, Nagios supports around 50 plug-ins, allowing users to do much more when it comes to network monitoring. You can download Nagios here. Sensu There are two versions of Sensu : the basic version and the Sensu Go version, which is designed to meet the needs of diverse users. Thanks to its outstanding features for custom script implementation, this application offers efficient healthmonitoring tactics. It combines plugins and gathers metrics data to produce thorough reports. It offers several integrated capabilities, like Splunk, ElasticSearch, ServiceNow, and many others, that make working more convenient. The process of agent identification is automated and has cutting-edge features like an Active directory. With the help of CRL support, this tool has external PKI verification. Using a productive enterprise data store, it improves working and scalability. Sensu uses transport architecture and uses MSSQL. If using the regular Sensu tool, network monitoring will be in code, however, Sensu Go displays data in different ways including graphs and trees. This tool can monitor servers, services, and applications, and supports more than 50 plug-ins. You can download Sensu here . Zabbix Due to its adaptable network monitoring capabilities, firms like Dell and Salesforce employ Zabbix . You can identify issues that need to be fixed by tracking network statistics, such as network bandwidth utilization , network health and configuration changes. Zabbix connects performance data via SNMP, IPv6, and the Intelligent Platform Management Interface (IPMI). It also allows you to automatically detect devices connected to your network before utilizing an out-of-the-box template to start network monitoring. Like Nagios, the architecture of Zabbix is server-client architecture. It operates with different versions of SQL which are MySQL, PostgreSQL, and SQLite. It can monitor both devices and servers, and generates data on free disk space, CPU load, network traffic statistics, memory consumption, application status, and much more. A great feature of Zabbix is that users can set up actions on remote machines, which are triggered automatically upon the occurrence of predefined events. Zabbix supports 14 plug-ins. You can download Zabbix here . Prometheus Prometheus is a popular open-source network monitoring tool with a sizable community. It was created especially fortime-series data monitoring. Time-series data can be recognized using key-value pairs or metric names. Every time an event is raised, Prometheus' Alertmanager gives you the option to examine notifications. If necessary, you can quiet notifications sent by Alertmanager via email, PagerDuty, or OpsGenie. Excellent visual elements in Prometheus let you choose among the browser, the template language, and the connection with Grafana. To personalize your Prometheus experience, you can incorporate numerous external data sources like StatsD, JMX, and Docker. Each Prometheus server is standalone, meaning they do not rely on remote servers or network storage. It uses PromQL for data, and multiple client libraries to match language used for users’ applications. The official Prometheus libraries include Go, Java or Scala, Python, Ruby, and Rust but there are also many more unofficial third-party libraries such as Bash, C, C++, and more. Prometheus supports 10 official plugins, and such as the client libraries, there are many more unofficial ones that can also be used. You can download Prometheus here . Final Thoughts The market for open-source Linux network monitoring solutions has been steadily expanding, which has paved the way for competition and encouraged developers to create even more effective software. The market for network monitoring is expected to increase from $27.6 billion in 2020 to $50 billion in 2027. While proprietary software may have limitations, open-source alternatives are affordable, powerful, and adaptable business tools. You can maintain your IT network while saving money and enjoying peace of mind by using open-source Linux network monitoring solutions. . Regardless of the sector you operate in, you must install some sort of network monitoring if your co. monitor, necessary, company's, network, reasons, modern, networks. . Brittany Day
Oct 28, 2022
•
102
network securityintrusion detectionnetwork monitoringEffective Network Intrusion Detection Guide: Snort Configuration Details
This document takes you through the basics of intrusion detection, the steps necessary to configure a host to run the snort network intrusion detection system, testing its operation, and alerting you to possible intrusion events. . Snort is a software-based real-time network intrusion detection system developed by Martin Roesch that can be used to notify an administrator of a potential intrusion attempt. The ever-increasing amount of Internet crackers, armed with "ready-to-run" exploits, as well as the sophisticated attacker that's intent on defacing your web page necessitates the use of a method to track their activity and alert you to this. Until now, intrusion detection devices were either dedicated-use commercial products, or not real-time and difficult to install. Snort is the solution for monitoring small TCP/IP networks where it is not cost-effective to deploy commercial products. Snort is an easy-to-use, "lightweight", and very functional alternative. What is Network Intrusion Detection? A Network Intrusion Detection System (NIDS) is a system that is responsible for detecting anamolous, inappropriate, or other data that may be considered unauthorized occuring on a network. Unlike a firewall, which is configured to allow or deny access to a particular service or host based on a set of rules. If the traffic matches an acceptible pattern, it is permitted regardless of what the packet contains. However, an NIDS captures and inspects all traffic, regardless of whether it's permitted or not. Based on the contents, at either the IP or application level, an alert is generated. Snort is a "lightweight" NIDS in that it is non-intrusive, easily configured, utilizes familiar methods for rule development, and takes only a few minutes to install. Snort currently includes the ability to detect more than 1100 potential vulnerabilities. Keep in mind that Intrusion Detection devices work in conjunction with other security measures, and are not a replacement for other good security practices. It is also quitefeature-packed right out of the box. Among its features include the ability to: Detect and alert based on pattern matching for threats including buffer overflows, stealth port scans, CGI attacks, SMB probes and NetBIOS queries, NMAP and other portscanners, well-known backdoors and system vulnerabilities, DDoS clients, and many more; Use syslog, SMB "WinPopUp" messages, or a file to alert an administrator; Develop new rules quickly once the pattern (attack signature) is known for the vulnerability; Record packets in their human-readable form from the offending IP address in a hierarchial directory structure. Used as a "passive trap" to record the presence of traffic that should not be found on a network, such as NFS or Napster connections; Used on an existing workstation to monitor a home DSL connection, or on a dedicated server to monitor a corporate web site Snort uses the popular libpcap library, the same library that tcpdump uses to perform its packet sniffing. Snort decodes all the packets passing by on the network to which it's attached by entering promiscous mode. Based upon the content of the individual packets and the rules defined in the configuration file, an alert is generated. Why Use Intrusion Detection? Intrusion detection devices are an integral part of any network. The Internet is constantly evolving, and new vulnerabilities and exploits are found regularly. They provide an additional level of protection to detect the presence of an intruder, and help to provide accoutability for the attacker's actions. Before Installing Snort There are a few things you should determine before you install snort. Do you have approval to run an intrusion detection device by your organization? Is the system you're installing snort on secure? The last thing you want is the feeling of that false sense of security that you get by looking at what you think is happening but really has been modified by an intruder. The use of OpenSSH is mandatory for remote access. Reading the SolarisSecurity FAQ and the Linux Security HOWTO should provide you with a starting point. Where are you going to put it? If you are simply trying to find out who is port scanning or attempting to attack your home system, it's an easy decision. However, placement in an organization may be more difficult. Is the date and time correct? Ensure the time and date are correct on the host that snort will be running on. Install the xntpd time server so you can be sure the time of the events you are recording is correct. Chances are it is included with or already installed on your system but may still need to be configured. Once you have found a suitable timeserver from the URL provided above, a root crontab entry such as the following should suffice: 00 * * * * root /usr/sbin/ntpdate -u The device may be placed outside an organization's firewall between the firewall and the external untrusted network. This allows snort to detect not only the attacks that may make it through the firewall, but also those that are blocked by the firewall. The presence of switches, routers and firewalls will all have an effect on the correct placement of the box. A decision must be made as to which network segment will catch the traffic you actually want to monitor. Placement of the NIDS on the local side of the firewall will allow the NIDS to monitor traffic that the firewall has already determined to be permissable, but not necessarily benign. This will, of course, not catch traffic that the firewall has already blocked, potentially masquerading port scans, probes and other types of attack. Single Interface The easiest configuration is a box with a single interface. The same interface that listens to the network traffic is the same one from which administration is done. Images Courtesy Network Flight Recorder This will be the typical configuration for home network users and administrators monitoring internal networks. Dual Interface In a dual-interface configuration, oneinterface is used to listen to network traffic in promiscuous mode while the other is used for remote administration. This type of configuration is used in environments where it is not possible to administrate the box from the same interface that is listening to the network traffic. In this configuration, the external interface should be well-protected and the box designed explictly for this purpose. The box should not be offering any network services except for ssh on the internal interface only. Images Courtesy Network Flight Recorder Installation of Snort The file INSTALL included with the distribution contains information on installing and configuration snort from the downloadable source code. It is very easy to compile, configure, and install. If you are a Red Hat or compatible user, a precompiled RPM file is available from . You will also need the libpcap-0.4 package which is included with all Linux distributions. The source code and other information are downloadable from . Installing the Snort Ruleset After snort is installed, you'll want to download the latest rules file. Currently there are two different rulesets that people use. A ruleset developed by Jim Forster can be downloaded from Another ruleset, developed as part of Max Vision's ArachNIDS work, is available from and updated hourly. The Max Vision ruleset is particularly nice because it follows the Common Vulnerabilities and Exposures (CVE) database, allowing people to refer to a particular vulnerability using a consistent name. From the CVE Frequently Asked Questions: "CVE is a list of information security vulnerabilities and exposures that aims to provide common names for publicly known problems. The goal of CVE is to make it easier to share data across separate vulnerability databases and security tools with this "common enumeration." " If you've installed the snort RPM, the /usr/sbin/snort-update script written by Dave Dittrich can be used to download thelatest Max Vision ruleset from cron: 00 00 * * * root /usr/sbin/snort-update -q It can also be downloaded from This assumes the wget package is installed, the local box can download the file at , and it can successfully deliver mail to an administrator. The snort-update script will place the vision.conf file in /etc/snort/vision.conf.new and an email notification will be sent to the local root account with the differences from the previous version, if any. You must then rename the vision.conf.new to vision.conf . You might also consider using the snort.org ruleset in addition to the Max Vision ruleset. This can be achieved by downloading the snort.org ruleset. Information on combining these rulesets together is included below. The backdoor-lib , misc-lib , overflow-lib and other similar files are included with the source code, but are pretty dated and not typically used. Before snort can be started, a few variables must be defined. Also included in the snort RPM is a file called rules.base which was derived from Max Vision's vision.conf file. It is a short file that contains a few variables that define your internal and external networks, hosts that snort should ignore portscans from, and on which networks snort should watch for portscans. It can also be downloaded from . A portscan is defined as TCP connection attempts to more than P ports in T seconds or UDP packets sent to more than P ports in T sections. Read Martin's "Writing Snort Rules" for a full description of portscan. You'll need to supply the information for your INTERNAL and EXTERNAL networks, and from DNS servers which tend to trigger the portscan detection. The rules.base file looks as follows: # # Taken and modified from "vision.conf", part of Max Vision's # ArachNIDs work. See /usr/doc/snort-1.6/README.snort-stuff for more # information on how to use this file. var INTERNAL 192.168.1.0/24 var EXTERNAL 63.87.101.0/24 var DNSSERVERS63.87.101.90/32 63.87.101.92/32 preprocessor http_decode: 80 443 8080 preprocessor minfrag: 128 preprocessor portscan-ignorehosts: $DNSSERVERS preprocessor portscan: $EXTERNAL 3 5 /var/log/snort/portscan.log # | # Log file (path/name) ----------------------------------+ # Ruleset, available (updated hourly) from: # # # Include the latest copy of Max Vision's ruleset include /etc/snort/vision.conf # # Uncomment the next line if you wish to include the latest # copy of the snort.org ruleset. Be sure to download the latest # one from # # include /etc/snort/06082k.rules # # If you wish to monitor multiple INTERNAL networks, you can include # another variable that defines the additional network, then include # the snort ruleset again. Uncomment the two following lines. # # var INTERNAL 192.168.2.0/24 # include /etc/snort/vision.conf # include other rules here if you wish. If you are on a dialup machine, the INTERNAL setting would be your dialup interface with a /32 subnet mask, indicating the host itself. Additionally, you may need to configure syslogd to log snort and other security events to a specific log file. Edit /etc/syslog.conf to log snort alerts, then signal syslogd to re-read the /etc/syslog.conf file: authpriv.* /var/log/secure.log [root@krypton ~]# /usr/bin/killall -HUP syslogd Using Preprocessors The preprocessor directives listed above are used to examine the data flow before the intrusion detection engine applies the ruleset to the packets. This can be used to modify the contents of the packet, or to signal the detection engine to not process a particular packet. The preprocessor http_decode: directive instructs the detection engine to convert the data within HTTP URI strings into a format that defeats attempts at eluding the content analysis strings used to examine HTTP traffic for suspicious activity. Supply the ports on which a web serveris running. The preprocessor portscan: directive is used to define the host or network for which snort should watch for a portscan. The /32 appearing after the IP addresses indicates CIDR notation for a 32-bit subnet mask (the host itself). For a Class C network, use /24 . It may also be necessary to exclude some hosts from triggering the portscan detection module. Boxes that generate legitimately generate traffic on a large number of ports in a short amount of time, including NFS or DNS servers are typical candidates. More on Patrick Mullen's portscan preprocessor can be found at . The portscan-ignorehosts preprocessor is used for this, and includes the hosts to ignore as its argument seperated by spaces: preprocessor portscan-ignorehosts: 63.87.101.90/32 63.87.101.92/32 You might consider trying it without the portscan-ignorehosts directive first, as you don't want to unnecessarily disable the ability to detect portscans if it's not necessary. The minfrag preprocessor checks for fragmented packets which can be used to disguise TCP packets from IP filters used in routers and hosts. Packets less than 512 bytes do not need to be fragmented with modern networks, and packets found smaller than that typically indicate attempts to subvert a firewall or intrusion detection. You should now be able to test your configuration file and the normal operation of snort: [root@krypton ~]# snort -d -l /var/log/snort -c /etc/snort/rules.base Initializing Network Interface... User level filter, protocol ALL, raw packet socket Decoding Ethernet on interface eth0 Initializing Preprocessors! ------------------------------------------------- Keyword | Preprocessor @ -------------------------------------------------http_decode : 0x8053070 minfrag : 0x8053290 portscan : 0x8053ce0 portscan-ignorehosts: 0x8054340 -------------------------------------------------InitializingPlug-ins! ------------------------------------------------- Keyword | Plugin Registered @ -------------------------------------------------content : 0x8052050 offset : 0x8052080 depth : 0x80520f0 nocase : 0x8052160 flags : 0x8052710 itype : 0x80528f0 icode : 0x8052a00 ttl : 0x8052b10 id : 0x8052bf0 ack : 0x8052cd0 seq : 0x8052dc0 dsize : 0x8052ec0 ipopts : 0x8054420 rpc : 0x8054670 icmp_id : 0x8054830 icmp_seq : 0x8054930 session : 0x8055300 -------------------------------------------------Initializating Output Plugins! ------------------------------------------------- Keyword | Output @ -------------------------------------------------alert_syslog : 0x8054a20 log_tcpdump : 0x8054ff0 ------------------------------------------------- +++++++++++++++++++++++++++++++++++++++++++++++++++ Initializing rule chains... 255 Snort rules read... 255 Option Chains linked into 140 Chain Headers +++++++++++++++++++++++++++++++++++++++++++++++++++ Performing Rule List Integrity Tests... ---------------------------------------Alert TCP Chains : OK Alert UDP Chains : OK Alert ICMP Chains : OK Log TCP Chains : Empty list... Log UDP Chains : Empty list... Log ICMP Chains : Empty list... Pass TCP Chains : Empty list... Pass UDP Chains : Empty list... Pass ICMP Chains : Empty list... --------------------------------------- -*> Snort! 192.168.200.189:32771 TCP TTL:42 TOS:0x0 ID:5410 ***F*P*U Seq: 0x0 Ack: 0x0 Win: 0x400 00 00 00 00 00 00 ...... The corresponding syslog entry looks like: Jun 18 00:48:31 krypton snort[8757]: MISC-Attempted Sun RPC high port access: 192.168.100.189:57554 -> 192.168.200.189:32771 Several perl scripts exist to process this information intoan HTML page which can be accessed periodically to determine what is occuring on the network. The snort2html is a perl script written by Dan Swan that does a nice job of producing useable information in HTML format. If you decide to save this in a directory accessable by a web server, be sure to apply the proper authentication mechanism to prevent outsiders viewing this file. It contains a great deal of helpful information to a potential intruder. It can be used as follows: [root@krypton ~]# /usr/bin/snort2html /var/log/auth.log This will produce an HTML file in /var/log/snort-log.html that is for use with the Max Vision ruleset and creates links to the CVE definition of each intrusion attempt. This version has been modified from the original to accept the filename from the command-line. You can edit this file to save the resulting HTML file in another location. Resources Lance Spitzner shows snort in action as he tracks an intruder and performs forensic analysis on the trails of the intruder. Fyodor has put together a document that describes the snort internals The snort download page includes pointers to source code, plugins to send snort output data directly to a database, the Win32 port, and the latest rulesets. The snort.org has a wealth of helpful information and documentation. Have questions or comments about this document? We'd love to discuss them with you- please leave a comment below! . Delve into Suricata, the advanced network threat detection framework. Configure triggers and observe network breaches in real-time.. Snort Detection, Network Monitoring, Intrusion Alerts, Open Source Solutions. . Brittany Day
Jan 14, 2022
•
102
network monitoringsecurity technologythreat managementExploring Network Intrusion Prevention Systems: Benefits And Challenges
Anyone keeping track of the security vendor/technology hype knows that IPS has quickly replaced IDS as the “next big thing. What NIPS Isn’t First and foremost, NIPS is not a tool for stopping elite crackers. That may be how it’s being marketed, but it’s crap. If you’re the type to fall for that sort of hype then you’re probably in a lot more danger than any given technology can help you with. A Simple Question Whether or not IPS is worthless or a godsend to your organization hinges on a single question – “How good is your organization at staying patched?. Appreciate the significance of Network Intrusion Prevention Systems (NIPS) and their role in enhancing cybersecurity measures.. Network Intrusion Prevention Systems, Cybersecurity Strategies, Threat Management. . Anthony Pell
Feb 11, 2010
•
102
security practicesnetwork monitoringautomationPort Scanning and Securing Linux Servers With Nmap Utility
Hi, and welcome back to another edition of Hacks From Pax. Today we'll discuss hardening Linux servers by scanning for unnecessarily open network ports, and we'll show you how to automate port scanning so you can easily monitor your network for vulnerabilities. . Portscanning, for the uninitiated, involves sending connection requests to a remote host to determine what ports are open for connections and possibly what services they are exporting. Portscanning is the first step a hacker will take when attempting to penetrate your system, so you should be preemptively scanning your own servers and networks to discover vulnerabilities before someone unfriendly gets there first. Any open ports that are unnecessary for proper system operation should be closed. Every open port is a possible access point for an unauthorized user, and every service accepting connections from the world could have a vulnerability. Even if you are diligent about applying patches, any unnecessarily running service is still a window an attacker could possibly climb through. One way of viewing open ports on your Linux system is with the netstat command. Issue the command netstat --inet -a to view both your established connections and open listening network ports. This command reads from your /etc/services file to determine the service name for a given port number, so seeing *:www under the Local Address heading indicates your server's port 80 is open and listening, not that there is necessarily a webserver running on that port. You should check the list and ensure that the servers listening are indeed desired, and if they are not, they should be disabled. For example, this output shows me that my system is accepting connections on the ports for www, ssh, smtp and https. [root@frylock /root]# netstat --inet -a Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 *:www *:* LISTEN tcp 0 0 *:ssh *:* LISTEN tcp 0 0 *:smtp *:* LISTEN tcp 0 0 *:https *:* LISTEN The best way of viewing open ports on a remote server is to use the nmap network scanning tool. It's recommended to use nmap from a system that is outside any firewall protecting your network, since the goal is to determine what network ports are visible and listening from a hypothetical attacker's point of view. Running the command nmap -vv -sS 192.168.1.1 would perform a SYN scan of only the common ports on the given ip address. [root@frylock ~]# nmap -vv -sS 192.168.1.65 Starting nmap 3.81 ( https://nmap.org/ ) at 2005-07-02 13:17 EDT Initiating SYN Stealth Scan against meatwad.linuxsecurity.com (192.168.1.65) [1663 ports] at 13:17 Discovered open port 22/tcp on 192.168.1.65 Discovered open port 25/tcp on 192.168.1.65 Discovered open port 443/tcp on 192.168.1.65 Discovered open port 80/tcp on 192.168.1.65 Discovered open port 1022/tcp on 192.168.1.65 Discovered open port 8080/tcp on 192.168.1.65 The SYN Stealth Scan took 0.24s to scan 1663 total ports. Host meatwad.linuxsecurity.com (192.168.1.65) appears to be up ... good. Interesting ports on meatwad.linuxsecurity.com (192.168.1.65): (The 1657 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 80/tcp open http 443/tcp open https 1022/tcp open unknown 8080/tcp open http-proxy MAC Address: 00:03:47:EF:42:42 (Intel) Nmap finished: 1 IP address (1 host up) scanned in 0.514 seconds Raw packets sent: 1665 (66.6KB) | Rcvd: 1670 (76.9KB) We can see that ports 22, 25, 80, 443, 1022 and 8080 are open and accepting connections. If we aren't using one or more of these services the unused ones should be disabled to lessen our security liabilities. This scan operates by sending a single SYN packet to each port, and listening for a returned SYN|ACK which indicates anopen port. Consult the nmap website for further information on the particulars of nmap usage. Nmap is an indispensable security tool that you should make a place for in your sysadmin toolbox. Nmap can be very useful for determining the outward facing open ports on your network when you remember to check, but with a little perl magic it can be useful for keeping an ongoing eye on your network as well. I've written a perl utility called NetDiff that scans a given network or multiple networks with nmap, stores the results in a database and then invokes diff on the result set to find newly opened and closed ports on a daily basis. NetDiff also will detect any systems newly added to or removed from the network, which can be useful for spotting, for example, that rogue wireless access point surreptitiously plugged into your network by the marketing department. NetDiff packages and documentation can be found on ftp.engardelinux.org. For those running EnGarde Secure Linux, I've written a WebTool module and packaged NetDiff rpm packages so you can simply install the packages and their required prerequisites and then configure your networks and later view the reports from within the EnGarde WebTool environment. NetDiff reports will display any network changes in a diff style format, prepending newly added lines with a '+' and removed lines with a '-'. For example, in the following NetDiff report we can see that the host at 192.168.42.64 was disconnected since the last scan, a host at 192.168.42.127 was connected, and a telnet service was started on 192.168.42.1 . Investigating these results against preplanned administration work is an exercise for the sysadmin reading the report. Perhaps the telnet port was opened for a reason, but perhaps a hacker has penetrated that system and opened the port for nefarious purposes. # # NetDiff Report # # Networks scanned : # 192.168.42.0/24 # # Last scan completed : 2005-07-03 02:05:43 # Scan started : 2005-07-04 01:00:01 # Scancompleted : 2005-07-04 02:06:31 # Hosts Scanned/Found : 35/35 # 192.168.42.64 ** MISSING ** 192.168.42.64 ** CHANGED ** -192.168.42.64 Status up -192.168.42.64 Extra Ports filtered 1662 -192.168.42.64 Port 80 http closed table 3 ----------------------------------------------------------------------------192.168.42.127 ** NEW HOST ** 192.168.42.127 ** CHANGED ** +192.168.42.127 Status up +192.168.42.127 Extra Ports filtered 1662 +192.168.42.127 Port 80 http closed table 3 ----------------------------------------------------------------------------192.168.42.1 ** CHANGED ** -192.168.42.1 Extra Ports closed 1663 +192.168.42.1 Extra Ports closed 1662 +192.168.42.1 Port 23 telnet open table 3 ---------------------------------------------------------------------------- Setting up netdiff to run daily will allow you a quick and easy way to view your recent network changes. Discovering an newly opened port on your network can be a telltale sign of a hacker's penetration or simply another sysadmin's mistake, but you'll know about it immediately and can take action to investigate the offending port and server. No scanning or reporting tool can replace a competent sysadmin, but a good reporting tool can guide a sysadmin towards anomalies on his or her network that require further sleuthing. Until next time, stay secure, and know your network like the back of your hand. I'll see you again soon, in the next episode of Hacks From Pax. -- Pax Dickinson has over ten years of experience in systems administration and software development on a wide variety of hardware and software platforms. He is currently employed by Guardian Digital as a systems programmer where he develops and implements security solutions using EnGarde Secure Linux. His experience includes UNIX and Windows systems engineering and support at Prudential Insurance, Guardian LifeInsurance, Philips Electronics and a wide variety of small business consulting roles. . Portscanning, for the uninitiated, involves sending connection requests to a remote host to determin. welcome, another, edition, hacks, today, we', discuss, hardening, linux, serve. . Anthony Pell
Feb 04, 2010
•
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Search Topics
Powered By
Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases
QUICK LINKS
subscribe to newsletters!
Like staying secure? So do we.
Sign up for updates, tips, and alerts!
Discover faster search, smarter navigation, and deeper Linux security insights. Read More