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 1 articles for you...
102
cyber threatsweb applicationLinux securityEnhancing Security in Linux Web Applications With Coding Strategies
Cybersecurity is not static; it's a game of continuous evolution. As web applications burgeon, so too do the threats against them. Within Linux environments, where flexibility and open-source attributes are prized, secure coding practices, Linux devs can stand on vigilant watch against these proliferating dangers. . Consider web scraping—as old as the web itself—leveraged for harmless data aggregation but capable of darker undertakings when turned against vulnerable sites. Its tools are often simple yet sophisticated enough to sidestep security measures thought ironclad. Web applications on Linux servers must be equipped with more than just basic defenses to withstand such relentless attempts at exploitation. So let’s get into the meat of this issue, touching on aspects as varied as understanding web scraping's Node. js-powered tactics and enacting robust protocols that fortify Linux web application security at its core. We'll explore how developers and system administrators can effectively anticipate attacks and shield their digital fortresses. The journey starts with recognizing that superior armor is crafted through knowledge of one's adversary and skillful application of defense strategies. Let's solidify your Linux stronghold against unwarranted data extraction and cyber intrusion. Insights into Web Scraping Techniques Using Node.js The essence of Node.js, designed for asynchronous event-driven JavaScript execution, makes it a potent tool for those who want to perform web scraping in JavaScript. This server-side platform equips developers with the capabilities to automate data extraction processes efficiently and, if not ethically constrained, potentially target the vulnerable facets of web applications. Here are a few critical Node.js security considerations viewed through the lens of web scraping, specifically concerning sidestepping security measures and web scraping blocks: Understanding HTTP/S Requests: The essential mechanism of sending HTTP/S requests lies atthe heart of web scraping. Node.js developers must grasp how these requests interact with web servers and what information they reveal about the scraper's intentions. User-Agent Spoofing: One-way scrapers slip past basic defenses by mimicking legitimate user behaviors via User-Agent spoofing. Modifying this header within a Node.js application can allow a scraper to pose as a different browser or device, evading detection mechanisms based on known scraper signatures. Handling Cookies and Sessions: Many sites track users' sessions using cookies. A sophisticated scraper built with Node.js will manage cookies like a regular browser, eluding simple security measures that filter out clients without cookie support. IP Rotation and Proxy Usage: Bypassing IP-based rate limiting or outright bans is achievable through proxy services and IP rotation strategies—a common technique in advanced web scraping scripts where each request appears to originate from a different source. Headless Browsers: Utilizing tools like Puppeteer or PhantomJS within a Node.js framework enables scrapers to render an entire web environment, complete with JavaScript execution and DOM interaction. This simulates a real user's browsing experience, allowing for circumvention of security measures that rely on the absence of certain client-side capabilities. DOM Parsing and Element Selection: Quality scraping hinges on accurately discerning and extracting data from the DOM. Node.js libraries such as Cheerio provide efficient parsing, enabling scrapers to select elements with precision akin to jQuery, thereby accessing content that less advanced methods might miss. Asynchronous Control Flow: Maneuvering through complex site navigation requires an asynchronous approach. With Node.js's non-blocking nature and async/await patterns, a scraper can navigate page sequences without getting tripped up by synchronous expectations. Rate Limit Evasion: By implementing delay tactics or randomizing request timings within aNode.js application, scrapers can attempt to mimic human interaction speeds, thwarting defense mechanisms designed to spot unnaturally rapid data queries. CAPTCHA Solving Services Integration: Some scraping applications go as far as integrating third-party CAPTCHA-solving services, allowing them to bypass one of the more stringent barriers in web security. The implications are clear: web applications require staunch, secure coding practices Linux experts must deploy to address these advanced scraping methods head-on. Cybersecurity professionals hope to develop robust defenses to guard against them only by understanding these techniques. Comprehensive Exploration of Secure Coding Practices for Linux Web Applications In the chess game of web application security, one must think several moves ahead. Developers, system administrators, and cybersecurity professionals orbiting Linux environments must arm themselves with secure coding practices—sharp tools to carve out robust defenses against sophisticated data extraction methods. This is a core part of wider security practices that must be adopted. Let’s lay down a groundwork of strategies and pragmatic approaches designed to elevate your Linux web application security posture to new heights: The Foundation of Secure Coding Security is not an afterthought—it's the blueprint upon which every code block should rest. Establishing a bedrock of secure coding guidelines is pivotal for any team striving for resilience in their web applications. This begins with ingraining industry standards such as the OWASP Top 10 , which crystallizes web applications' most critical security risks. Internalize Best Practices: Digest and integrate core principles from secure coding standards tailored for Linux environments, ensuring these practices become second nature within your development cycle. OWASP’s Top 10 Awareness: Familiarize yourself with each entry in OWASP's compendium; understanding threats like injection flaws or brokenauthentication paves the way for preemptive defense construction. Embrace Security-centric Design Philosophy: Prioritize security at every phase—from initial design through development to deployment—fostering an organizational culture deeply rooted in mindful coding habits. Adapt Guidelines For Node.js: While broad precepts are universal, specificity matters. Adapt secure coding guidelines to address nuances specific to Node.js and Linux environments. This means understanding the ecosystem, its modules, and how they interact within a Linux server context to harness their full potential for security. Leverage Secure Coding Tools: Employ tools designed for Node.js, such as linters and static analysis packages, that enforce secure coding standards automatically. In a Linux setting, tools like ESLint with plugins for security can identify code that may lead to vulnerabilities. Develop Custom Security Rules: There's value in customization—define your own rules based on your application's unique requirements or organizational policies. The aim is to configure an environment where automation encourages and enforces secure practices. Focus on Dependency Management: Dependencies in Node.js are double-edged swords; they offer functionality but open doors to vulnerabilities if not properly managed. Use package managers with features that spotlight security when managing these dependencies on Linux servers. Continuous Education and Training: Secure coding is an evolving discipline. Regularly scheduled training sessions keep teams up-to-date with the latest threats and mitigation techniques, ensuring that your defense mechanisms evolve as rapidly as new challenges arise. In-depth Input Validation and Sanitization Surface-level measures no longer suffice in the relentless battle against cyber threats; the depth of your defense often determines victory. Therefore, input validation and sanitization must be meticulously managed to repel attackers seeking to exploit Linux webapplication security through malicious input. Employ Whitelisting: Allow only pre-approved inputs, shunning the risk-laden approach of blacklisting where dangers are bound to slip through an ever-growing list of exceptions. Enforce Strict Type Constraints: When data is expected in a specific format or type, enforce these expectations rigidly. Such type constraints filter out mismatched inputs before they can cause harm within your Node.js application on a Linux server. Utilize Sanitization Libraries: Lean on libraries crafted to clean data. They strip inputs of elements that could trigger unwanted behaviors or security vulnerabilities. Regular Expressions with Caution: While powerful, regular expressions should be used judiciously as their complexity can inadvertently introduce risks—aim for simplicity and clarity wherever possible. Validate File Uploads Meticulously: This extends beyond checking file extensions or MIME types; consider implementing antivirus scanning or file content analysis to fortify against compromised uploads. Secure Session Management Navigating the intricacies of session management is akin to fine-tuning a high-performance engine—it requires precision, understanding, and constant vigilance. For Node.js applications in the Linux realm, maintaining the sanctity of user sessions is key to repelling unauthorized access and preserving session integrity. Implement Robust Cookie Security Attributes: Ensure cookies carrying session tokens are secured with attributes such as `HttpOnly,` `Secure,` and `SameSite.` These help mitigate risks like XSS and CSRF attacks by asserting control over how browsers handle cookies. Manage Session Expiration: Expire sessions after inactivity to reduce the risk window. Post-authentication, revamp session tokens to guard against fixation attacks while maintaining a seamless user experience. Leverage Advanced Token Techniques: Where suitable, adopt token-based authentication mechanisms like JWT(JSON Web Tokens) . If employing this method within Linux environments, ensure payload encryption and proper management of the token lifecycle. Harden Against Enumeration Attacks: Design your session identifiers to be unpredictable and resistant to enumeration. This can be achieved through high entropy strings that don't divulge timing or order information. Sessions in Distributed Systems: If your architecture spans multiple servers or services, implement a synchronized session management strategy that consistently sustains security measures across different components. Encryption and Secure Data Storage In the vault of Linux web applications, data is the currency. Protecting it isn't just a priority; it's a necessity. Encryption serves as the armored car for data in transit and at rest, ensuring that even malicious actors intercept your precious cargo, they're left with an indecipherable puzzle. TLS/SSL Protocols: Implement TLS (Transport Layer Security) protocols to encrypt data as it flows through network pipes. This means acquiring and maintaining valid SSL certificates for your Node.js applications on Linux servers. Encrypt Sensitive Data at Rest: Use strong algorithms and strategies to transform active records into unreadable blocks of encrypted information when stored. Consider tools like LUKS for full disk encryption or database-specific encryption features in Linux environments. Key Management Practices: Safeguard encryption keys with the same ferocity as the data itself—utilize key management solutions that offer secure storage, rotation, and access controls. Data Masking Techniques: Minimize exposure by masking portions of the information when displaying sensitive data. Employ strategies that permit necessary interactions without revealing complete details. Seek Libraries With Proven Track Records: Select cryptographic libraries widely trusted within the development community and undergo regular security audits; keeping these up-to-date isparamount. Error Handling and Logging The drama of a system failure or a security breach unfolds quickly, and the narrative it leaves behind is crucial for forensic scrutiny. In Linux web application security, error handling, and logging are the scribes that record these events precisely, ensuring that they inform future safeguards rather than expose vulnerabilities. Discreet Error Messages: Design error responses to provide necessary feedback without unveiling system internals. Overly informative messages can serve as hints for attackers—avoid them. Structured Log Management: Establish rigorous logging practices that capture enough detail for analysis but exclude sensitive user data. Use structured formats like JSON to facilitate parsing and investigation in Linux environments. Centralized Logging System: Implement a centralized log management solution conducive to aggregating logs from various sources, offering an overarching view of your Node.js application's health and security posture. Monitor Log Integrity: Protect your logs as fervently as any other aspect of your system. Regular checks against tampering will ensure the reliability of this critical diagnostic tool. Automation in Log Analysis: Apply automated monitoring tools capable of alerting personnel to anomalous behavior indicative of a security incident or systemic issue. Authentication and Authorization Mechanisms In the realm of Linux web application security, establishing who someone is and what they are permitted to do is akin to distributing keys and laying out the permissible paths within your digital kingdom. Authentication verifies identity; authorization ensures rights are properly allocated. Each is a vital element in the secure coding arsenal. Multi-Factor Authentication (MFA): Go beyond simple passwords with MFA, requiring additional verification methods such as tokens or biometrics—a practice that significantly elevates hurdles for intruders. Authorization Checks: Embed granular controls that consistently enforce who has access to what. In Node.js, middleware can act as a gatekeeper, asserting permissions before granting access to specific routes or resources. Password Management Best Practices: Enforce strong password policies and use secure, salted hashing techniques for storage. Never underestimate the potential of compromised credentials when inadequately protected. Role-Based Access Controls (RBAC): Implement an RBAC system where roles are clearly defined along with their associated privileges—this simplifies management while enhancing security by ensuring least privilege access principles. JSON Web Tokens for Session Management: Utilize JWTs carefully to maintain user state in your applications—an approach involves validation at every request and aids in keeping sessions secure. Preventing Injection Attacks The defense against injection attacks in web applications forms one of the cornerstones of secure coding practices Linux devs need to get to grips with. Recognized as a notorious threat vector, these attacks turn benign application queries into malicious commands. Preventing them requires a combination of stringent coding techniques and vigilance. Use Prepared Statements: When querying databases within Node.js applications, prepared statements with parameterized queries are your best defense, creating a bulwark that injection payloads can't penetrate. Employ ORM Frameworks: Object-Relational Mapping (ORM) frameworks abstract database interactions and inherently sanitize inputs—take advantage of tools like Sequelize or TypeORM for added layers of security. Validate All Inputs: Never trust external input; rigorously validate and sanitize all data from user forms, URL parameters, headers, and cookies to eliminate any executable code before it reaches your logic. Escaping Data: When direct interaction with SQL or command lines is unavoidable, ensure proper escaping is employed so that special characterscannot manipulate the intended query or command. Regular Security Audits and Penetration Testing Complacency is the enemy of security. In the context of Linux web applications, it's not whether attackers will try their luck but when. Regular security audits and penetration testing are the drills that keep your sentries sharp and your battlements sturdy. Scheduled Code Reviews: Commit to routine examinations of your application’s source code. This practice often unveils vulnerabilities that automated tools might overlook. Automated Vulnerability Scanning: Integrate automated scanners into your development process. Tools like OWASP ZAP can provide continuous insight into potential weaknesses. Engage in Penetration Testing: Ethical hackers simulate cyberattacks during penetration tests, challenging your defenses in real-world scenarios—enlist them regularly to probe for soft spots. Test Across Different Layers: Ensure that both front-end and back-end components undergo scrutiny. Each layer—from servers and databases to interfaces—has unique chinks in its armor. Adapt to Findings Swiftly: Post-audit, prioritize discovered vulnerabilities based on risk severity; then act swiftly to patch gaps, revise flawed logic, or enhance protective measures. How Can I Close Security Gaps with Monitoring and Incident Response? A Linux web application's security strategy arsenal is incomplete without the dual forces of monitoring and incident response. These proactive and reactive measures work in tandem to identify and manage potential breaches effectively when they occur. Implement Advanced Monitoring Solutions: Deploy real-time tools that can detect anomalies. Use solutions capable of sifting through vast amounts of data and alerting teams to unusual patterns to enhance data extraction prevention techniques and avoid other malicious activities. Establish Alert Thresholds: Define clear criteria for abnormal behavior within your systems. Setting theseparameters ensures that alerts are meaningful and warrant immediate investigation. Orchestrate an Incident Response Plan: Develop a comprehensive plan detailing steps to be taken in the event of a security breach. This should include initial containment strategies, communication protocols, and recovery processes. Practice Incident Scenarios: Conduct regular drills based on potential breach scenarios to ensure all team members know their roles during an incident—such preparedness can significantly mitigate damage. By meticulously establishing monitoring systems and honing incident response plans, Linux web applications can quickly close gaps when breaches occur and potentially prevent many from ever happening. Our Final Thoughts on Enhancing Security in Linux Web Applications with Advanced Secure Coding Practices As we encapsulate our exploration of advanced secure coding practices, we must acknowledge their vital role in safeguarding Linux web applications. The strategies we've delineated are not merely suggestions but essential components of a robust security framework designed to withstand the sophisticated methods of unauthorized data extraction and cyberattacks. The commitment to deploying these practices is a testament to due diligence in an era where digital threats are as inevitable as diverse. It's a continuous pursuit that demands vigilance, agility, and an unyielding resolve to adapt. For those tasked with defending Linux web applications, embracing these stringent measures is more than just enhancing security—it's about preserving trust and upholding the integrity that clients and stakeholders expect. In closing, let this be both a reflection on what has been learned and a clarion call for action—a reminder that in the dynamic landscape of cybersecurity, the only constant is change itself. Encourage a culture of continuous learning and improvement within your teams. While today’s protective measures may be formidable, tomorrow’s challenges require evengreater resilience and innovation. . Web applications on Linux face advanced threats; implement secure coding practices to protect against web scraping and cyberattacks.. cybersecurity, static, it', continuous, evolution, applications, burgeon. . Brittany Day
Mar 05, 2024
•
102
network securityscalabilitysecure codingBuilding Scalable Software Architectures on Linux for Security and Growth
Scaling a software application successfully is no small feat. Like raising a child, it requires planning, having the right foundations, and being prepared to adapt along the way. Just as kids outgrow clothes and need bigger shoes, our software creations need room to grow and stretch as user demand escalates. That's where scalability comes in, or the capacity to handle increased usage without breaking strides in current successes and projects. . This guide will walk you through the practical strategies and techniques to build scalable software to handle growth and keep users happy. We'll cover scaling concepts, planning, design, testing, and management. We'll see how Linux provides the perfect flexible and stable platform for scalable applications. With the proper knowledge and Linux network security toolkits, you can develop software that gracefully grows with your business. Understanding Scalability Scalability is a software system’s ability to handle increasing volumes of data, traffic, or demand without impacting its performance or reliability. As your application grows, you want it to scale up seamlessly. There are two primary types of scalability: Vertical Scalability Vertical scaling involves increasing an individual server's processing power, memory, storage, or network bandwidth. This can be upgrading to a server with more CPUs, adding more RAM, or increasing your network bandwidth. The advantage is simplicity, but the downside is the cost and capacity limits of a single machine. Horizontal Scalability This type of scaling means distributing the load across multiple servers, typically by adding more nodes to a system by adding more application servers behind a load balancer. This allows near-unlimited expansion if your architecture supports distributing work across nodes. The complexity is that you must handle distributed computing network security issues. A well-designed system will allow vertical and horizontal scaling to accommodate different growth needs.Key factors influencing scalability include workload variability, data volumes, caching, component interfaces, and architectural bottlenecks. By keeping scalability principles in mind early when building systems, you can develop the capacity to scale seamlessly. Why Is Linux Ideal for Scalability? Linux provides an ideal operating system for building scalable applications. Its open-source nature, robust architecture, and powerful network security toolkits enable cost-effective scaling. Some key Linux features that promote scalability include: Modular kernel and process isolation allow the capability to run processes independently without interference, enabling applications to partition. CGroups limit and allocate resources like CPU, memory, and disk I/O per process group and help avoid the " noisy neighbor " issue. Advanced networking stack supports load balancing and high throughput needs and handles vast connections. Security modules like SELinux and AppArmor provide secure scaling and tight permissions at scale to ensure data and network security. Package management easily installs and updates dependencies, keeping libraries optimized. The kernel is highly customizable , can be tuned and optimized as needed, and can be tweaked for performance at scale. Multi-threading enables admins and organizations to manage concurrent tasks efficiently and leverage multi-core systems. With these capabilities, Linux can readily handle increased loads. Since it's open source, Linux can be tailored to meet specific scalability requirements. The vibrant Linux community also provides guidance and support for scaling challenges. Designing Scalable Software Architectures Now we get to the fun part - getting to build your software for scale! When designing software architectures for scalability on Linux, it's essential to embrace distributed system principles rather than building large, monolithic applications that break functionality apart intoindependent microservices that can each be scaled as needed. Microservices enable true horizontal scalability. When getting started, ensure each service shares nothing with other services and uses external storage like caches and databases to avoid storing client state internally. This makes services stateless and allows traffic to be distributed across instances. Asynchronous processing is also crucial to use for message queues and to decouple tasks or prevent blocking responses. Databases should be shared and replicated to prevent contention and availability problems and other network security issues. Add redundancy at all levels, from load-balanced frontends to multi-master database backends. Monitor performance closely and simulate loads to catch bottlenecks before they impact users. By following these steps, you'll have a resilient architecture ready to handle whatever scaling challenges come its way, maintaining data and network security. Critical Implementation Considerations Using Containers and Clustering Linux containers like Docker and orchestrators like Kubernetes make scaling straightforward. They allow packing services and dependencies into portable, isolated environments. Auto-scaling clusters can then dynamically launch containers based on demand. This provides immense flexibility to scale up or down. Containers are lightweight, which enables high density and efficiency. Distributing Databases Distributed stores like Cassandra, CockroachDB, and Elasticsearch make them highly available. Replication provides redundancy, while partitioning divides data to relieve contention. Distributed databases scale horizontally across commodity servers and can handle node failures. Open-source options like Cassandra offer flexibility when choosing a distributed database, while cloud-native options like Athena and Snowflake provide fully managed services. When selecting a distributed database solution, it's essential to carefully evaluate the features and benefits of managedservices like Athena vs Snowflake. Key factors include query performance, concurrency and workload management, caching and optimization capabilities, ecosystem integration, and pricing models. Choosing the right database will assist in ensuring data and network security, as well as securing your services from any cyber security vulnerabilities. Load Balancing Workloads Load balancers like Nginx distribute incoming requests smoothly across backend application instances. This allows horizontal scaling while frontends remain scalable and reliable. Load balancers prevent request flooding and also provide health checking. Use cookie-based sessions for stickiness. Asynchronous Task Processing Message queues and pipelines decouple processing from user interactions. They enable executing intensive jobs asynchronously for faster responses and throughput. Queue servers like RabbitMQ and Kafka provide guarantees and verify data and network security. Caching and Performance Tuning Caching speeds up reads substantially by avoiding trips to databases. Tune cache invalidation and time-to-live values based on access patterns. Profile and tune the Linux kernel using tools like sysctl and irqbalance. Look at saturable CPUs, context switching, and I/O waits. The Foundation of Security: Developing Secure Software for Linux Of course, it’s always important to remember to ensure you have both data and network security when building scalable systems. While Linux provides a robust and secure OS foundation, the applications running on top play a pivotal role in making sure you improve the security posture within the system overall. As such, developing secure software designed explicitly for Linux is crucial if you want to keep your plans safe. At its core, writing secure code requires a mindset shift from solely focusing on functionality to also considering potential cybersecurity vulnerabilities. This involves understanding common weaknesses, such as input validation, while adopting approacheslike network security threat modeling early in design. A few specific Linux security best practices include: Leveraging Linux capabilities and data and network security modules like SELinux to strictly limit application permissions and access. Default to least privileged models. Rigorously sanitizing all inputs and never trusting user data. Assume all client input is malicious. Using safe Linux APIs instead of direct system calls whenever possible. This avoids the ability to bypass security controls. Securing interprocess communication and shared resources like files/sockets. Use security mechanisms like file permissions. Handling multi-threading carefully to avoid race conditions. Having a robust response plan for cyber security vulnerabilities, including reporting methods and disclosure. Keep dependencies updated and use trusted sources when embedding third-party components. Logging extensively for auditing and analysis, but handling logs securely. Testing complex areas like encryption implementation for correctness. Secure development requires forethought, diligence, and a proactive mindset. However, building Linux applications securely from the ground up prevents countless headaches. It also protects users and contributes to the stability of the broader ecosystem. With some knowledge and priority, Linux developers can make security a cornerstone of their craft. Final Word on Building Scalable Systems with Linux Scaling software successfully requires forethought and diligence. By understanding core scaling concepts, planning capacity wisely, architecting for growth, and implementing pragmatically on Linux, you can build systems ready for primetime. Linux provides the perfect blend of flexibility, robustness, and power for scaling. With the right foundations and pragmatic approach, your applications can flourish, not crack, as demand swells. Use the strategies covered here to scale new heights on Linux, and make sure you maintain constant data and networksecurity against any and all cybersecurity vulnerabilities. The sky's the limit! . Explore strategies for scalable software development in Linux, focusing on security through containerization, microservices, CI/CD, and secure coding practices. Scalable Software, Linux Scalability, Security Practices, Load Balancing, Distributed Systems. . Brittany Day
Aug 07, 2023
•
102
cyber defensesecure codingopen source securityEnhance Your Cybersecurity: Open-Source SAST and DAST Tools Explained
As open-source software becomes increasingly common in the infrastructure of businesses, it is essential to ensure the security of the software being relied upon. An increasingly popular cyber security solution is open-source SAST (Static Application Security Testing) and DAST (Dynamic Analysis Security Testing) security scanning, which give IT technicians and developers the ability to access the code of a certain piece of software to remove threats or improve the strength of its security. . Software scanning tools allow developers and users to scan the code of the programs they are using to check for security flaws. The two types of security tools, SAST and DAST, each have their strengths and weaknesses. Running these tools (and your wider organizational systems) through an open-source operating system like Linux will provide you with additional security and peace of mind and increase control over your hardware infrastructure. This is what you need to know about SAST and DAST on Linux and why it is important for your organization. What Is Open Source Security? Open-source is software that is accessible to outside users, who can change or share the source code at will. The source code, which open source refers to, is what can be used by developers or technicians to modify the nature of the software. This is used to improve performance, eliminate any technical gremlins, or bolster security. Naturally, open-source security allows you to be incredibly flexible with your security processes because you can immediately dive into the software and fix any issues. There is no need to wait for a software upgrade, call out a specialist, or leave yourself with lasting software problems at the whim of the proprietary software vendor that could damage your organization’s health and reputation. Given the relentless demand for the latest software and technology solutions within businesses today, it is little surprise that open-source security processes are an increasingly prevalent means of tacklingsecurity problems. Using the increasingly popular open-source Linux operating system offers additional security benefits due to its modular construction. This limits user access to applications and separates them from each other, meaning that if there were a cyber-attack, less damage would be done in a single breach. Despite the benefits associated with open-source development discussed above, not every open-source security tool is equal, and there are a few different approaches to consider. This includes SAST and DAST tools, which we will cover in more depth below. What Are SAST and DAST Tools? Ultimately, SAST and DAST tools have the same goal- to improve the security of code within software. However, they take different approaches to solving this problem, which is important to note if you consider utilizing them. What Types of Vulnerabilities can SAST Tools be Used to Find? Firstly, SAST tools are used to examine software source code, which is still under development and not out on the open market. SAST tools can be of great assistance if you are trying to identify and fix bugs during the development phase of a piece of software or technology. SAST tools work by analyzing code to look for vulnerabilities. They use the white box testing methodology, meaning the program is never actually run and is “tested” only on a logical level. By scanning the code, SAST tools can identify vulnerabilities such as: weak random number generation SQL injection cross-site scripting buffer overflows Since SAST tools are usually used earlier in development, they can prevent the need to pull a piece of software later in the development cycle, which could cost a lot of time, money, and even reputational damage. To further improve the efficiency of the software development process, you can add a SAST tool to an integrated development environment (IDE). Essentially, this alerts the development team of any technical glitches or software vulnerabilities as they work, speeding up thesoftware creation process and minimizing the chance of errors. What Types of Vulnerabilities can DAST Tools be Used to Find? Conversely, a DAST tool is designed for use after a piece of software has already been completed. Unlike a SAST tool, a DAST tool does not focus on troubleshooting issues within the code. Instead, it attacks a system from the outside inwards, hacking the program using a variety of approaches - including through exposed HTML and HTTP. Unlike SAST tools, DAST tools use a black box approach, meaning that the program is only tested from the outside without any knowledge of the inner workings, the way a hacker would likely attack it. DAST tools are useful for finding: configuration problems issues with error handling input and output issues Unlike SAST tools, DAST tools can not tell you from where in the code an error originates–it is by design as blind as a real user of the software would be. A DAST tool is particularly useful if you have an existing system or piece of software that is likely to suffer from a certain cyber-attack. For example, if your organization operates an online retail store, then there are certain attacks you should be vigilant of. A DAST tool can be programmed to run a simulation of these hacks to expose any potential weaknesses within your infrastructure. There is a tendency for businesses to focus on deploying either a SAST tool or a DAST tool, focusing on one as though it is better than the other. This is rarely the case because they fulfill different roles within your cyber security processes. By using both tools, you safeguard yourself both at the software development and deployment phases. Which Open-Source Security SAST and DAST Tools are Available? There are various strong open-source security tools available, and choosing between them can be difficult. Here are a few options to consider: Zed Attack Proxy (ZAP) : ZAP is a DAST tool available on Windows, Mac, and Linux that is designed primarily fortesting web applications by using penetration testing. ZAP is a popular tool that is used by dozens of other services and has a beginner-friendly user interface. GoLismero : GoLismero is another DAST tool and is available on Windows, Mac, BSD, and Linux. GoLismero is a bit less beginner friendly than ZAP, as it does not have a UI–it is installed and run solely via the command line. However, it is very robust as it consolidates the results of security frameworks including sqlmap, xsser, openvas, dnsrecon, and theharvester, and has several output options. SonarQube Downloads : SonarQube is an SAST tool that can analyze 17 different languages including Java, Javascript, Python, HTML, and CSS. It also has a dynamic UI, a community forum, and thorough documentation. There are several expanded versions of SonarQube with more features and support for additional programming languages, but only the “Community Edition” is free and open-source. w3af: w3af is a DAST tool designed primarily to test web applications. It is a framework specifically made to be easy to extend and incorporate into other projects. w3af can be downloaded on Linux, Mac, and BSD (it is also possible to run on Windows, but it is not officially supported or tested.) What Are the Top Five Things I Should Look for in an Open-Source Security Scanning Tool? With so many software scanning tools available, it can be helpful to narrow your focus when deciding what tools to use. Tips for choosing the right scanning tool include: Easiness to Use (Especially if You’re a Beginner) Not all software scanning tools are beginner friendly. Some tools, like the aforementioned GoLismero, can only be run or even installed using the command line. On the other hand, tools like ZAP and SonarQube are designed to be easier to use thanks to their detailed user interfaces, making them a good starting point. What Programming Languages It Can Check Not all tools are made for checking all types of programs. While sometools, like SonarQube, can check most types of code, tools like ZAP and w3af are made for testing certain types of programs, like web applications. Limited False Positives Software scanning tools sometimes make mistakes by flagging safe code as dangerous. Attempting to fix these nonexistent flaws can lead to wasting time by rewriting code for no reason, so it is important to look for scanning tools that have as few false positives as possible. What Flaws It Can Find (Don’t Rely on Just SAST or DAST) No one software can find every exploit. Because SAST and DAST tools use fundamentally different methodologies to find flaws and are meant to be used in different stages of development, they should ideally both be used in order to help find more types of errors and bugs. Active Support, Updates, and Community (You Don’t Want a Tool that Can’t Find New Vulnerabilities) When using any open-source software or tool, it is important to check that it is up to date and frequently updated since out-of-date code can be a security risk. Ensuring that the tools you are using are up-to-date is especially important with a security tool like software scanners so that they can find the latest exploits. What Are Some Strengths and Weaknesses of Open-Source Testing Tools? There are many strengths and weaknesses to be aware of when considering the use of open-source testing tools and open-source technology in general. To start with the advantages, open-source testing tools can save your organization substantial money. When you have an open-source variant of a software solution, you can make changes yourself, adapt the software to your specific needs, and even operate without a license, all of which cuts a lot of unnecessary costs. Furthermore, you will (hopefully) be able to identify problems within the system before they cause any significant damage. This could save your organization a substantial amount in damages, potential losses (both data losses and financial losses), and reputationaldamage. Another key advantage of open-source testing tools is increased agility. When you can dive into open-source code at any time, fixing issues and improving performance are made far more efficient. Technically, anyone can work on the software, which eliminates potential delays in waiting for system updates or a professional fix. When you are growing an organization quickly, delays in software updates or bug fixes can stop your progress overnight, so having user-focused testing tools allow you to constantly build upon your base layer solutions. Know that Open-Source Tools Are Not Perfect While open-source tools can provide many advantages, they are not perfect. Commercial tools often have more features. For example, as mentioned before, the paid, closed-source versions of SonarQube offer significantly more features and compatibility with more programming languages. The open-source version is more of a “try before you buy” where features are intentionally limited in an effort to draw clients to their subscription model; it’s not necessarily a limitation of open source itself. However, many open-source scanning tools have large user bases with lots of community support, meaning that bugs can be fixed just as quickly, if not faster, as a proprietary closed-source software. Ultimately, it is up to developers to weigh the pros and cons of open-source tools against the needs of their projects. Final Thoughts on DAST vs. SAST: Which One Is Better? While SAST and DAST are both useful for testing the security of programs, they use fundamentally different methods for finding exploits. SAST programs analyze the code itself; while an error checker that analyzes code sounds more thorough, not all programming errors can be found in code. The fact that SAST never executes the program means that it can not find runtime errors or exploits that can be taken advantage of by a user. While DAST never looks at the code of the program it is testing, it is able to find runtime issuesby executing the program. It is unfair to say that either SAST or DAST is better–they both serve different purposes. Since SAST analyzes code, it is usually used earlier in development to assist with programming. On the other hand, DAST is usually used after the programming is finished as a way of finding exploits in the complete software. Both tools should be used hand in hand for ideal error prevention, and a best-practice security strategy should incorporate both SAST and DAST tools in its software development cycle. . Open-source SAST and DAST tools are essential for enhancing software security. By integrating them into development, vulnerabilities are identified early and reduce risks.. Open Source Security,SAST Tools,DAST Tools,Secure Coding. . Yosef Davidowitz
Jun 13, 2022
•
102
buffer overflowmemory safetysecure codingUnderstanding Buffer Overflow Risks and Solutions for Linux Programming
A buffer overflow occurs when a program or process tries to store more data in a temporary data storage area than it was intended to hold. Since buffers are created to contain a finite amount of data, the extra information can overflow into adjacent buffers, corrupting or overwriting the valid data held in them. . By: Suhas Desai Buffer overflows are a fertile source of bugs and malicious attacks. They occur when a program attempts to write data past the end of a buffer. A buffer is a contiguous allocated chunk of memory, such as an array or pointer in C. Limitation of C and C++ is there are no automatic bounds checking on the buffer where user can write past a buffer as given in example. Note: All examples are compiled on Linux platform having x86 configuration. int main () { int buffer [10]; buffer[20]=10; } After execution of this program it won’t give errors but program attempts to write beyond the allocated memory for the buffer which results for unexpected output. Example: void function (char *str) { char buffer[16]; strcpy(buffer,str); } int main() { char *str=”I am greater than 16 bytes”; function(str); } This program is guaranteed to cause unexpected behavior, because a string (str) of 27 bytes has been copied to a location (buffer) that has been allocated for only 16 bytes. The extra bytes run past the buffer and overwrite the space allocated for the FP, return address and so on. This corrupts the process stack. The function used to copy the string is strcpy, which completes no checking of bounds. Using strncpy would have prevented this corruption of the stack. Example: int main() { char buff[15]={0}; printf(“Enter your name:”); scanf(buff,”%s”); } In this example, program reads a string from the standard input but does not check strings length. If the string has more than 14 characters, then it causes a buffer overflow as scanf() tries to write the remaining characterpast buff’s end. Note: One character is always reserved for a null terminator. The result is most likely a segmentation fault that crashes the program .In certain conditions, the users will receive a shell’s prompt after the crash. Even if the shell has restricted privileges, they can examine the values of environment variables; list the current directory files to detect the network with the pig command. Writing Buffer Overflow exploits: 1. Example of an exploitable program - Lets assume that we exploit a function like this: void lame (void) { char small[30]; gets (small); printf("%sn", small); } main() { lame (); return 0; } Compile and disassemble it: # cc -ggdb program.c -o program /tmp/cca017401.o: In function `lame': /root/program.c:1: the `gets' function is dangerous and should not be used. # gdb program /* short explanation: gdb, the GNU debugger is used here to read the binary file and disassemble it (translate bytes to assembler code) */ (gdb) disas main Dump of assembler code for function main: 0x80484c8 : pushl %ebp 0x80484c9 : movl %esp,%ebp 0x80484cb : call 0x80484a0 0x80484d0 : leave 0x80484d1 : ret (gdb) disas lame Dump of assembler code for function lame: /* saving the frame pointer onto the stack right before the ret address */ 0x80484a0 : pushl %ebp 0x80484a1 : movl %esp,%ebp /* enlarge the stack by 0x20 or 32. our buffer is 30 characters, but the memory is allocated 4byte-wise (because the processor uses 32bit words) this is the equivalent to: char small[30]; */ 0x80484a3 : subl $0x20,%esp /* load a pointer to small[30] (the space on the stack, which is located at virtual address 0xffffffe0(%ebp)) on the stack, and call the gets function: gets(small); */ 0x80484a6 : leal 0xffffffe0(%ebp),%eax 0x80484a9 : pushl %eax 0x80484aa : call 0x80483ec 0x80484af : addl $0x4,%esp /* load the address of small and the address of "%sn" string on stack and call the print function: printf("%sn", small); */ 0x80484b2 : leal 0xffffffe0(%ebp),%eax 0x80484b5 : pushl %eax 0x80484b6 : pushl $0x804852c 0x80484bb : call 0x80483dc 0x80484c0 : addl $0x8,%esp /* get the return address, 0x80484d0, from stack and return to that address. you don't see that explicitly here because it is done by the CPU as 'ret' */ 0x80484c3 : leave 0x80484c4 : ret End of assembler dump. 1.a. Overflowing the program # ./program xxxxxxxxx
Feb 12, 2010
•
102
risk managementsecurity analysissoftware securityInterview: Gary McGraw Discusses Software Security and Exploitation
Gary McGraw is perhaps best known for his groundbreaking work on securing software, having co-authored the classic Building Secure Software (Addison-Wesley, 2002). More recently, he has co-written with Greg Hoglund a companion volume, Exploiting Software , which details software security from the vantage point of the other side, the attacker. He has graciously agreed to share some of his insights with all of us at LinuxSecurity.com.. LinuxSecurity: Gary, please give our readers a brief introduction to your new book, Exploiting Software: How to Break Code (ISBN 0-201-786-95-8). Who does the book appeal to? Where can it be purchased? Gary McGraw: Traditionally, the field of computer security has been about network and operations people -- think network administrators and IT staff. The basic idea was to build a wall around your networks, protecting your vulnerable stuff (inside) from bad people (outside). The problem with this approach is twofold. First off, "perimeter security" is, at its essence, reactive. Secondly, there is no such thing as a well-defined "perimeter" anymore now that distributed systems are so widespread. The advent of Web services, mobile code, and Internet-based computing makes the notion of perimeter security seem quaint. Furthermore, the attackers have a distinct advantage, since they only need to find one flaw to exploit, while the defenders have to find and remove them all. In the end, the vulnerable stuff is software, and a lot of software is so buggy that it's almost impossible to protect. Because of all this, there has been an increasing interest in software security. That means one of the key questions to consider is, how do you harden software against attack? The only reasonable way to do this is to deeply understand just what attacks are. After all, how can you know that your company's critical software is secure, and that it has been built with security in mind, if you really know nothing about what the attacks on it are like? In thissense, Exploiting Software is useful to operations people, and to their management. By knowing how the software living on and making up their network is likely to be attacked, a good network admin is better equipped to manage risks. Only by understanding how easily buggy software can be compromised can CIOs begin to apply the kind of risk management that business demands to the software they rely on. Our book is also useful to software developers. It is vital that the people who build our systems (including Linux) learn to look at their software creations not just as a collection of features, but as potential targets for hackers and their nefarious exploits. It only makes sense for builders to get into the mind of their attackers so they know what they are really up against. For more information about buying a copy of Exploiting Software for yourself (and your entire development staff), check out www.exploitingsoftware.com. The publisher, Addison-Wesley Professional, also has a website too. LS: Can you offer a brief description of your background and that of your co-author, Greg Hoglund? How did you two meet or decide to co-write a book? How long have you been in the software security field? How would you say this collaboration has enriched the book? GM: First, I'll answer for myself. I am a scientist at heart, and I've been playing with computers ever since I got an Apple II+ in 1981. I studied the lucrative field of Philosophy at the University of Virginia and, inspired by the Pulitzer Prize winning book by Douglas Hofstadter Godel Escher Bach , I ended up earning a dual PhD in Computer Science and Cognitive Science from Indiana University (where Doug was my thesis advisor). Around 1985, I got interested in the 'Net. In 1993 we put up one of the first 400 nodes on the Web (Yahoo was a complete list of all websites back then). In 1995, Java came out, and being a programming languages and Web junkie, I downloaded it. Investigating itsinteresting claims of being a "secure" computing platform led to my first book, Java Security , written with Ed Felten of Princeton. After that, the need for some good work in software security became obvious. In 2001 I wrote the first book in the world on software security, called Building Secure Software with John Viega. Greg Hoglund started out as a black hat. In contrast to my academic background, he was completely self taught, and has the innate ability to think like a hacker. In fact, he wrote the first rootkit for Windows NT, and started in the process. We became friends some years ago and he agreed to co-write this book just after the publication of Building Secure Software . The idea was to look at a large corpus of attacks and exploits and see if we could discern any patterns in these attacks. Greg's expertise was absolutely critical to this undertaking, and his thinking pervades the technical aspects of the book. LS: You have previously written a book called Building Secure Software , which covered the design and implementation of secure code for the software developer. Can you explain why we might also a primer for black hats, such as Exploiting Software ? GM: Actually, Greg and I call Exploiting Software the black hat book (in contrast to BSS which is the white hat book)! Together, the two books make up the "black and white series." The reason we saw the need for the black hat book is that we strongly believe that you simply cannot build a defensible, secure system without knowing how people will attack it. The bad guys already understand software. In fact, they are software people. They know how to write code, they know what bugs to look for, and they know how to exploit them. They can hold a security patch up against a broken piece of software and use it as a roadmap for writing a new exploit. Unfortunately, on the other side of the divide, most security operations people do not understand software. They are excellent firewalland router admins, but they don't code. That's a problem. LS: What are some of the most major pitfalls that software designers fall into? Can your book help to avoid these problems? GM: In the book, we provide a set of 49 attack patterns. Attack patterns are directly related to pitfalls and problems that we see in real production software today. One of the points I like to emphasize is the difference between bugs and flaws in software. Bugs are simple mistakes in code leading to problems like buffer overflows; flaws are mistakes in design. It turns out that a lot of software is flawed. In fact, if you step back and look at a multitude of security problems over time, you'll find that about 50% of them are due to bugs and 50% due to flaws. There are too many common design failures to list exhaustively here. But here are a couple of examples... Object Oriented programming is the latest, greatest widespread coding paradigm, and it can indeed be very useful. But the distributed code model has a cost: each class (and possibly every method) is expected to do its own error handling, meaning that there is not necessarily an inherently centralized error handling mechanism. This means that it becomes difficult to determine exactly what will happen at various points of failure. Keeping track of precisely what is going on in the software as it throws exceptions willy nilly is difficult at best. Error handling is complex, and complexity is a great friend to attackers. Without some ability to manage errors in a consistent system wide fashion, it becomes nearly impossible to be sure that nothing intentionally bad could be made to happen. Then there is the more general concern that software designers tend to be a very feature-oriented crowd. They build things, and things have features. So they naturally default to thinking about security as a set of features (think SSL or access control). The problem is that security is an emergent property of a complete system. Related to this "featurism," is a related problem involving trust. Developers tend to have too much trust to their users, and do not treat user input with due suspicion. They think, "users want to access these features," instead of "attackers might abuse my system in surprising ways." These are just a few high level issues that can render software insecure. There are many, many more where these came from. LS: What practical steps can be taken out of the book, from a security analyst or administrator's point of view, to further secure their systems given that their software may be riddled with flaws? Anything beyond keeping up with their vendor's patches? GM: I hope to convince operations people to intuitively distrust software. They should be equally skeptical of the claims of security software vendors to solve all of their problem with a magic whatzit (like magic crypto fairy dust). Any security person can learn to become aware of programming languages that software is written in, and think through the security implications there. If you want secure software, you cannot just rely on (spurious) claims about security. For example, in order to 'prove' that the software is secure, a security vendor might tout their EAL level. But the Common Criterion is not a fail proof approach. In fact, it is really a "least common denominator" approach to security; because ultimately all it requires is that the vendors demonstrate specific claims that they themselves make about security, such as how well the code was protected while it was being written. But this may have no relationship to real security! That is, some of the vendor claims may not be meaningful to the consumer; and there is really no way to show that any set of claims put together somehow collectively equal "secure software" for all possible situations. This is particularly confusing for the market and its constituent consumers, because the market may not be versed in the subtleties of why various claimsmay not add up to something secure enough. It is at this point that we can circle back to the point of the book---flawed software, and how it is actually exploited. Consider that it can be quite difficult to make code secure when you insist on writing it in C. Only those who need very low level functionality should use a low-level language like C, which provides too much rope for a majority of programmers. Perhaps there should be some sort of a license for writing C! In the end, an administrator or security person should understand that programs written in C are much more likely to be insecure than those written in a modern type safe language like Java or C#. The CIO and/or top operations people can keep this in mind when they decide what software to deploy to solve a particular problem. One way for administrators to deal with software they cannot completely trust is to be very careful to not give software excessive privileges. The manner in which software is installed can make all the difference in the world from a security perspective. In fact, a bad deployment can ruin otherwise pretty darn good software! LS: How difficult is it to get started? How long would it take for today's regular non-security-focused developer or administrator to use these techniques to begin to test and improve the security of the software for which they are responsible? GM: Getting started on software security can be as quick and painless as reading some of the now available books and articles. But getting things going on a really secure footing can be a large undertaking if your organization is big. Consultants like Cigital can sometimes help with this. Of course, even without achieving excellence in software security, there is plenty of value to be found in taking the first steps, such as simply regarding software with the proper dose of suspicion and keeping privileges to the minimum necessary. LS: Your book contains an entire chapter on disassembling andreverse engineering. What is your opinion of security by obscurity? Are open systems less secure because the code is freely available, without having to be disassembled? GM: Firstly, I should say that security by obscurity simply doesn't work, with one exception. That exception is that if you carefully design a new piece of software, have it tested very carefully for security and have it extensively vetted by software security experts, and then don't publish the design, then it does work to make the software harder to exploit. So, security by obscurity only helps if the software is already rock solid. On the other hand, the "open source is more secure" debate is a red herring. All the big software houses, think Microsoft, pay entire armies of people to look at the code. In fact, the economics of the situation are on the side of the closed source guys. Analyzing code for exploitable bugs is a hard job best left to professionals who like to be paid for their work. Because they have deep pockets and can pay people to work hard on software security, Microsoft has greatly improved the security of its code in recent years. Crispin Cowan tried to set up a community-based economy for security analysis of open source called Sardonix. Unfortunately, it didn't work; mostly because there are not enough really qualified people who are interested in doing security analysis for free or for brownie points. In the end it is ridiculous to say that "all bugs are shallow." That's only true for the easy bugs. Some bugs are subtle and simply not easy to detect, even by hordes of people. A related problem...at its core, open source tends to be grown organically. Open source people are feature-oriented, and as we have already discussed, security is not a feature. However, I would like to add that open source has improved from a security perspective, probably just as much as closed source. Partially because of guys like Crispin Cowan and increased scrutiny due to recentattacks. I believe that this improvement was mostly due to the efforts of companies like IBM, and, to a lesser extent, SuSE and Red Hat rather than by some non-economic, non-subsidized means. LS: Your book mentions that black box case testing software that is touted as the final solution for software security is really no panacea. Can you expand upon this point? GM: Black box application testing solutions are not worth much money! Rudimentary dynamic testing that runs 100 canned tests and declares victory is really rather silly. How can you know if the inputs you ended up testing (especially with canned tests) are the ones that would uncover defects? It's true that this sort of testing can help determine "badness." That is if a black-box test suite finds problems, you are in very big trouble indeed. But if all tests are successfully passed, that says little about your real security posture. Don't forget that the basic problem of software security is usually at least as much one of design as of implementation. Black box tests cannot find design flaws (unless they get lucky). A much more useful idea is that of code scanning, looking at source code for potential vulnerabilities. A number of open source scanners can be found (ITS4 and flawfinder to name two), but you have to make sure you understand what the scanner is scanning for in the code. Ask yourself, are you sure that the scanning rules are right? What will they catch, and what might they miss? If you understand what they are looking for and why, code scanning can be very useful. LS: One of the chapters of your book is about the infamous buffer overflow problem. Can you briefly explain to our readers what exactly a buffer overflow is, and why it has become such an issue? GM: Buffer overflows occur because of bad language design (think C) and sloppy code. The best solution is for more software to be written with better languages, like Java and C#, instead of C or C++. Essentially,a buffer overflow happens when information is written over parts of memory that were not intended to hold that information. Think about pouring too much beer in a glass. By overwriting the parts of the memory that hold critical information such as return addresses, an attacker can get an attack payload to execute, with whatever privileges the executing program may have. We explain this in great detail in the book. Direct memory manipulation comes down to us from the days when memory was exceptionally expensive and precious, and had to be used with extreme frugality. But nowadays, there is memory to waste, and programs grab huge swaths of it and rarely release it, treating it as a raw sea of bits. Handling memory properly is something that is beyond the current understanding of many programmers, and the issue is made worse by the use of common, powerful system calls whose security implications may not be well understood by those people using them. LS: In your book, you emphasize the importance of risk analysis to overall software security. Can you please explain this concept to our readers? Why should we not aim for perfectly secure software? GM: We can't just stop using software because its not absolutely provably secure. The only way to make your computer really secure is simply to turn it off. Whenever we add functionality (or turn the machine on), we open the door to security issues. You just have to ask yourself if the functionality you want to utilize is worth the risk you take on. In many cases, the answer will be that it is, but it is critical to realize the basic fundamental nature of this tradeoff. Software security is about minimizing the risk inherent in the additional functionality that software supplies. That's why it is a risk management game. LS: What concrete improvements would you like to see in the field of software design in the future? GM: Less is more in security. Turn off unnecessary functionality and services. Thefeature-oriented set tend to think more is better, but more is less secure. Bloatware is bad. I always ask developers: who plans on having less code at the end of the year as the beginning? Very few of them say they do! Less stuff would be better. Complexity, network-based design, and extensibility (involving mobile code that does stuff on the fly and arrives arbitrarily) are the friends of the attacker. I call these the Trinity of Trouble (also covered in Exploiting Software ). When the Internet toaster is finally available, it will give an attacker the chance to burn your breakfast! LS: What are your future plans? Do you plan on writing any other books/articles? GM: When I write a book, I get to a point where I am absolutely sick of writing, and I say to myself "I'll never write another book again!" And then later, I forget the pain and do it again. I'm still somewhat in the sick of writing phase, but I'm sure I'll soon forget.. Uncover valuable perspectives on application security through our unique dialogue with Gary McGraw regarding vulnerabilities in software.. Software Security, Attack Techniques, Risk Assessment, Code Vulnerabilities, Security Practices. . Brittany Day
Jul 30, 2004
•
102
security practicesopen source toolssecure codingInterview With Wietse Venema: TCP Wrapper and Postfix Security Insights
Wietse Venema is best known for the software TCP Wrapper, which is still widely used today and is included with almost all unix systems. Wietse is also the author of the Postfix mail system and the co-author of the very cool suite of utilities called The Coroner's Toolkit or "TCT". He is currently working at the Thomas J. Watson Research Center and he has gratiously agreed to allow us to catch up with him and and see what he's been up to lately.. Wietse Venema is best known for the software TCP Wrapper, which is still widely used today and is included with almost all unix systems. Wietse is also the author of the Postfix mail system and the co-author of the very cool suite of utilities called The Coroner's Toolkit or "TCT". He is currently working at the Thomas J. Watson Research Center and he has gratiously agreed to allow us to catch up with him and and see what he's been up to lately. Linuxsecurity.com: Thanks for taking the time to interview with us. How you doing these days? The most we hear from you is when Postfix is updated, the mailing lists, or something like that. What are you up to? Wietse: I have been finishing things, so that I can start work on new projects. After a major documentation rewrite for the Postfix mail system, I finished the manuscript for a book on computer forensic analysis with Dan Farmer. When I finish something, I normally start reading everything that I can lay my hands on and then inspiration comes. Linuxsecurity.com: On your website you mentioned you go bike riding, weather permitting, how's the weather been where you are this year? Wietse: It has been fairly typical here in southern New York state. We dig ourselves out from the snow a few times in January and February. Once the snow is gone in March, we spend quality time walking up a hill or riding a bike. Many several former railroads are/were converted into trails, and riding them is fun. Unlike Europe, where I grew up, the roads in southern New York state are notreally safe for riding a bicycle. Linuxsecurity.com: You have a suite of tools available on your website. Any new ones coming out that address basic fundamental security practices that still aren't followed or are you going to add any new functionality to your existing programs? Wietse: Some tools such as TCP WRAPPER are complete, and adding more features does not make them more useful. I would update them only so that they survive changes in operating systems, language compilers and/or network protocols. Some tools such as SATAN have served their purpose, and now have historical value only. Linuxsecurity.com: Does the continued success of TCP Wrapper surprise you? If so, why is that? What does TCP Wrapper have that makes it so valuable today. Perhaps the biggest virtue is that tcp_wrappers works as expected. This means that not only the software is relatively error free, it is also possible for human beings to install, configure, and forget tcp_wrappers without getting into trouble. It does not matter how well software is written when people can't figure out how to use it, or when it has sharp edges that make it unsafe to use. Being safe and secure is hard enough with software like tcp_wrappers that spans only a few thousand lines of code. With a 10 times larger system such as Postfix, even relatively error-free software contains a number of errors, and one has to build additional safety features into the architecture to prevent accidents from happening. Just like elevators have safety brakes that prevent them from crashing into the basement, Postfix has safety brakes that most people never notice until they are needed. Linuxsecurity.com: Postfix is a really good Mail Transport Agent (MTA), I've been using it for a long time and I set it up for someone any chance I get. Why did you decide to write a new MTA instead of scaling down an existing MTA? :-) Wietse: Indeed, why would anyone spend so much time writingyet another UNIX-based mail system, when Sendmail and qmail already existed? When I was looking for a programming project, neither mail system was a desirable option for me, and enough people felt the same way. Writing a new mail system from scratch was a change from previous projects. Normally I would retrofit security features almost invisibly, either by replacing an existing server such as portmap by a hardened version that was 100% compatible, or by adding a very thin layer such as tcp_wrappers. In the case of the Postfix mail system, there was no way that the changes could be made in an invisible manner. Linuxsecurity.com: What is your take on spam and the role the MTA plays in helping to prevent it? Wietse: Stopping email that contains spam is not fundamentally different from stopping email that contains viruses. In both cases, complex content analysis is better done outside the mail system. That allows people to choose the best mail system and the best spam/virus software for their environment. And in both cases, a lot of spam or viral email comes from systems that have no business sending email directly across the Internet. These are often PCs on residential networks that have been compromised via some worm of virus, and that are under remote control by criminals that use those systems to send spam and/or to infect more systems. These rogue systems can often be recognized by the way they implement the email protocols wrongly, if not by their residential IP address. Blocking direct mail from rogue systems is best done by the ISP that hosts those systems, but that happens rarely. The next best solution is to block direct mail from rogue systems at the receiving end, and that is where Postfix can help. Linuxsecurity.com: In one article, I wrote about how attackers are still breaking into computer systems using well-known exploits. Any ideas on how to help instill basic security practices in administrators andvendors? Wietse: I think that learning by example is a good way to bring the point across. This is what Dan Farmer and I attempted years ago with our white paper on improving the security of your system by breaking into it. I have the same experience when explaining how to build more secure software. People just don't see that there is a problem until you can show good examples of software that does not do the things that it obviously was meant to do. Security problems happen when there is a mismatch between expected behavior and actual behavior. Linuxsecurity.com: How did you get into the forensics side of computers? Wietse: The initial motivation for getting involved with computer forensics was to reconstruct computer break-ins, so that I could prevent them from happening again. An amazing amount of information can be found after an incident. As computers become more complex, humans have less control over when and where information is stored, and how that storage is recycled when information is discarded. Because of this it is practically impossible to erase all information about an incident from a disk, without physically destroying the hardware. Erasing all memory is difficult too, if you don't want to draw attention by crashing the system. How much reconstruction is possible depends only on the amount of skill and effort you're willing to put in. Linuxsecurity.com: You and Dan Farmer still work on The Coroner's Toolkit (TCT). What research, seminars, or open source programs you working on in forensics? Wietse: We just finished a manuscript for a book on computer forensic analysis that we hope will come out this year. In this book we write about things that we learned after we released the TCT. For some experiments we used the TCT, and for other measurements we wrote a few new tools. When this book is published I will be happy to turn my attention to other projects. Linuxsecurity.com: We just wanted to catchup with you and see how things were going. Can you please give us a final statement about keeping our systems secure? Wietse: You don't make a system secure by patching the holes - if the system wasn't built to be secure then it never will be. Linuxsecurity.com: Wietse provided this quote: "As long as there is support for ad hoc fixes and security packages for these inadequate designs and as long as the illusory results of penetration teams are accepted as demonstrations of computer system security, proper security will not be a reality." Roger Schell et al., Preliminary notes on the Design of Secure Military Computer Systems, 1973. Archive of seminal security papers at https://seclab.cs.ucdavis.edu/projects/history/seminal.html Linuxsecurity.com: Okay one last thing, where were you and who drew that caricature on your website? Wietse: The caricature was drawn, by an artist whose name I do not know, at a conference dinner in 1997 when the Forum of Incident Response and Security Teams (www.first.org) met for its annual conference in Bristol, UK. I have supported this organization for many years, and I even had the privilege of spending more than the maximal time as its chair. Duane Dunston is an Information Technology Specialist (Security) for the National Climatic Data Center. He was previously a contractor for STG Inc. for the same organization. He received his B.A. and M.S. degrees from Pfeiffer University and he has his GSEC certification from SANS . Hey, Ann Curry! . Wietse Venema explores how TCP Wrapper and Postfix continue to influence modern security strategies in the current landscape.. Wietse Venema, TCP Wrapper, Postfix Mail Agent, Computer Forensics, Security Practices. . Duane Dunston
Jul 09, 2004
•
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