Explore top 10 tips to secure your open-source projects now. Read More

×
Alerts This Week
Warning Icon 1 576
Alerts This Week
Warning Icon 1 576

Stay Ahead With Linux Security News

Gitea 1.27 Hero Esm H350
Security Vulnerabilities Price Tag%201security advisory moderate

For organizations that run a self-hosted Git platform, it’s no longer just about hosting static code repositories. Today, Git servers are responsible for deployment pipelines, API tokens, SSH keys, package repositories, and the automation scripts that push code directly. Confirm that the upgrade addresses known vulnerabilities but also provides production environments. . That makes them trusted systems within the development environment and attractive targets for attackers looking to move...
1 min read Security Vulnerabilities
23.Tablet Connections Esm H350
Server SecurityPrice Tag%201data privacy automation

Every system admin has lived through the same Monday morning ritual. A queue of forty tickets, half of them password resets, permission errors, or disk space warnings that any experienced technician could resolve in under two minutes. The other half require actual judgment. For years, automation promised that software would eventually sort the two apart on its own. That promise is now being tested in production Linux environments. . Early results are reshaping how IT teams think about tier-1...
3 - 5 min read Server Security
8.Locks HexConnections CodeGlobe Esm H350
PrivacyPrice Tag%201data collection automation

You're running a web scraping project to collect pricing data from e-commerce sites. You set up a pool of datacenter proxies, launch your scripts, and within minutes — banned . CAPTCHAs everywhere. Your data pipeline stops before it really begins. . It's a frustrating scenario that plays out daily in ad verification, market research, and multi-account management. The website doesn't know you're doing legitimate research or monitoring. It just sees traffic coming from IP ranges it recognizes as...
4 - 7 min read Privacy
6.EmailConnection Touch Esm H350
Security Trends Price Tag%201security advisory social engineering

Business Email Compromise used to be a numbers game — mass-blasted emails, broken English, an obvious "URGENT WIRE TRANSFER" subject line. That era is over. Generative AI has turned BEC into a tailored, low-noise operation that mimics writing style, voice, and even video presence. This piece looks at what's actually changed under the hood, what defenders are testing in response, and why so many organizations are still structurally unprepared for it. . The Infrastructure Problem Nobody Wants to...
4 - 7 min read Security Trends
7.Locks HexConnections Esm H350
Security Trends Price Tag%201cybersecurity Linux documentation

Linux operating systems have gained prominence due to their stability, adaptability, and excellent security options. In the case of developing documentation, designing cybersecurity dashboards, or educational material, visuals are of vital importance when it comes to making things clear. The use of icons allows one to understand the message regarding alerts, authorization, encryption, authentication, or the state of the system just by looking at the visual cue without having to read long...
5 - 9 min read Security Trends
Filter%20icon Refine news
X Clear Filters
X Clear Filters
View More

Get the latest News and Insights

Get the latest Linux and open source security news straight to your inbox.

Community Poll

More Polls

Should Linux servers automatically install security updates?

No answer selected. Please try again.
Please select either existing option or enter your own, however not both.
Please select minimum {0} answer(s).
Please select maximum {0} answer(s).
/main-polls/157-should-linux-servers-automatically-install-security-updates?task=poll.vote&format=json
157
radio
0
[{"id":506,"title":"Yes \u2014 critical security patches should install automatically.","votes":0,"type":"x","order":1,"pct":0,"resources":[]},{"id":507,"title":"No \u2014 every update should be tested before deployment.","votes":0,"type":"x","order":2,"pct":0,"resources":[]},{"id":508,"title":"Only critical vulnerabilities should auto-install.","votes":0,"type":"x","order":3,"pct":0,"resources":[]},{"id":509,"title":"I patch when Reddit starts panicking.","votes":0,"type":"x","order":4,"pct":0,"resources":[]}] ["#ff5b00","#4ac0f2","#b80028","#eef66c","#60bb22","#b96a9a","#62c2cc"] ["rgba(255,91,0,0.7)","rgba(74,192,242,0.7)","rgba(184,0,40,0.7)","rgba(238,246,108,0.7)","rgba(96,187,34,0.7)","rgba(185,106,154,0.7)","rgba(98,194,204,0.7)"] 350
bottom 200
Loading...

Explore Latest Linux Security news

We found 49 articles for you...
83
11.Locks IsometricPattern Esm H240
Price Tag%201security advisorydependency managementLinux administration

Understanding Trojans in jQuery: Mitigation Strategies for Linux Admins

Security professionals and system administrators face growing cyber threats in today's digital environment, making defending systems increasingly challenging. A recent discovery by Phylum revealed a sophisticated large-scale operation targeting Node Package Manager (npm) , GitHub repositories, and Content Delivery Networks (CDNs) via trojanized versions of the jQuery JavaSecript library . . To help you secure your dependencies against these attacks, I’ll explain the attack mechanics and potential implications for Linux admins while outlining actions you can take to defend against such sophisticated threats. Understanding Trojanized jQuery Attacks JQuery is a fast, small, feature-rich JavaScript library used widely across web development projects for its simplicity and ease of use. Unfortunately, its widespread adoption makes it an attractive target for cybercriminals who disguise malicious code within legitimate-looking jQuery scripts to sneak it onto websites and applications for further malicious activities, including data exfiltration, deployment of additional malware , or establishing backdoors for access. The attack tactics involve threat actors publishing compromised versions of jQuery packages on npm or infiltrating existing packages and using CDNs for distribution across the web. With GitHub acting as a repository host and CDNs playing such an integral role in distribution across the internet, the scope and scale of this attack are alarming. Malicious code embedded within compromised scripts carefully designed to avoid detection can remain dormant until specific conditions are met or remotely activated by an attacker. What Are the Security Implications for Linux Admins? Linux admins overseeing web servers and development environments face major security threats fr om these attacks, especially from jQuery-powered apps whose widespread usage reassures a false sense of security. The trust placed in package repositories and CDNs creates an illusionary sense of safety forapplication owners and CDNs alike. The effects are profound, from data loss and theft to increased costs due to downtime for maintenance tasks on applications running on Linux systems to downgrades on services rendered vulnerable by these attacks. Repercussions include: Compromise of Web Applications: Malicious jQuery libraries may compromise web applications and expose sensitive user and corporate data. Threatened System Integrity: Compromised libraries may provide entry points for attackers looking to escalate privileges and compromise Linux systems hosting these applications. Damaged Trust: Relying on external resources such as npm, GitHub, and CDNs is often problematic because incidents like these erode trust between essential services and users, further complicating dependency management and code deployment strategies. Practical Defense Strategies Against Trojanized jQuery Attacks Linux administrators need a multi-layered defense strategy focused on vigilance, validation, and integrity to counter current and potential future threats. This strategy should include: Integrity Checks and Code Review: Employ integrity checks on imported libraries and conduct thorough code reviews for critical dependencies like jQuery. This will provide early warning of compromised packages. Secure Dependency Management: Maintain strict control over package sources. Whenever possible, always rely on verified and secure sources when selecting dependencies. Tools like npm audit can assist in identifying known vulnerabilities in packages, and private registries may help maintain approved packages that have already been verified and tested. Continuous Monitoring and Alerting: Implement continuous monitoring for web applications and servers and alarm mechanisms that detect unusual activities, such as outbound connections, that could indicate data exfiltration attempts. Education and Awareness: Educate development teams on the risks associated with external dependencies.Foster a culture that prioritizes scrutinizing third-party code. Disaster Recovery and Response Planning: Establish an incident response and disaster recovery plan. Should an attack compromise services or data, having access to secure backups to restore services or data quickly is critical. Contribute to Security Communities: Join security communities and platforms. Sharing information about potential threats can enable others to bolster their defenses early, contributing to a more robust collective security posture. Our Final Thoughts on Securing Your Dependencies Against Trojanized jQuery Attacks The discovery of trojanized jQuery attacks illustrates the ever-evolving landscape of cyber threats, underscoring the importance of constant vigilance for Linux administrators. In addition to keeping systems and networks secure, their responsibility also encompasses protecting dependencies and third-party code as part of an overall proactive security approach. By employing rigorous security practices, promoting awareness campaigns, and encouraging community collaboration efforts, it is possible to reduce the risk of such sophisticated attacks. . Grasp the methods to safeguard your libraries against malicious jQuery intrusions with essential tactics and knowledge tailored for Linux system administrators.. Trojanized jQuery, Cyber Threat Strategies, Linux Dependency Security. . Brittany Day

Calendar%202 Jul 10, 2024 •User Avatar Brittany Day Hacks/Cracks
209
7.Locks HexConnections Esm H240
Price Tag%201intrusion detectionsecurity practicesattack prevention

Mitigation Techniques For Espionage Threats On Linux Systems

Cybersecurity is an ever-evolving environment, with threat actors continually finding new methods of breaching systems and stealing sensitive information. Recent research has shed light on the sophisticated operations of threat groups and botnets that have successfully penetrated Linux server domains, creating significant risks to organizations globally. . Let's examine this concerning trend and the mitigation strategies you should implement to secure your systems and sensitive data. Security Researchers Are Witnessing Increased Espionage on Linux Platforms Security researchers have historically prioritized APT attacks targeting Windows platforms over those targeting Linux servers; however, scientific research sectors utilize Linux servers extensively as they host valuable and sensitive data that must remain protected at all costs. Threat actors have taken note and have started targeting these servers instead for malicious purposes. Recent research identified UTG-Q-008, an active threat group that targets Linux systems for espionage. Through comprehensive tracking efforts, it was confirmed that this malevolent group utilizes a massive botnet network to engage in its activities against research and education institutions. Notably, up to 70% of its infrastructure includes springboard servers—each activity using different sets. Its prolonged operations reveal the significant resources and expertise invested in such campaigns. Unveiling Botnet Threats in Linux Server Domains One of the more alarming trends observed in recent espionage activities targeting Linux servers has been the increased involvement of botnets. These malicious networks provide threat actors with virtually unrestricted resources, enabling them to carry out large-scale operations successfully. Using new springboard servers for each attack activity poses unique challenges to traditional defense mechanisms based on Indicators of Compromise (IoC) intelligence systems. Threat groups such as UTG-Q-008 utilize techniqueslike scanning and brute-forcing to gain unauthorized access to Linux servers. By employing distributed SYN scans and brute-force attempts, attackers can identify and compromise vulnerable systems through sophisticated exploitation techniques. Botnets' involvement in spy activities underscores the ever-evolving nature of cyber threats and the necessity of strong defense strategies against these attacks. Practical Recommendations for Mitigating Espionage Threats on Linux Systems With increasing threats aimed at Linux systems, administrators must strengthen the security posture of their systems to mitigate threats posed by threat actors and increase defenses against any potential espionage activities. Here are some practical recommendations designed to bolster your defenses: Implement Strong Authentication Mechanisms: For added protection from brute-force attacks on Linux servers, require complex and unique credentials for user accounts to secure them with complex credentials that prevent unauthorised access through brute-force methods. Maintain Regular Patch Management: Install software updates and security patches as quickly as possible to address known vulnerabilities that threat actors could exploit to compromise Linux systems. Network Segmentation and Access Controls: Establish robust network segmentation measures and strong access controls to prevent unauthorized access to sensitive systems and information. Monitoring and Intrusion Detection: Deploy advanced monitoring tools and intrusion detection systems to monitor for suspicious activities, unauthorized access attempts, or network traffic anomalies that might indicate suspicious activities or unusual traffic flow patterns. Enhance Incident Response Planning: Create effective incident response plans to swiftly address security incidents, limit breaches' impact, and restore compromised systems' integrity. Security Awareness Training: Provide users and administrators with training on cybersecurity bestpractices, social engineering threats, and the importance of remaining vigilant against potential attacks. Linux administrators who take a proactive and multi-layered approach to cybersecurity can protect their servers against potential espionage threats and ensure the integrity of data hosted on Linux servers. Our Final Thoughts on the Rise in Linux Espionage Threats Recent research findings demonstrate the increased espionage threats targeting Linux systems and underscore their need to prioritize cybersecurity measures and strengthen defenses against cyber threats. By understanding the methodologies employed by threat groups and botnets targeting Linux server domains, organizations can equip themselves with the knowledge and tools necessary to defend against sophisticated espionage activities and protect valuable assets from malicious actors. . Uncover the escalating risks posed by espionage activities aimed at Linux platforms and identify robust tactics to fortify your security measures.. Linux Espionage Threats, Botnet Attacks, Cybersecurity Alert, Protect Linux Systems. . Brittany Day

Calendar%202 Jun 05, 2024 •User Avatar Brittany Day Security Trends
Banner 2 1028x280 1708121730 1 1771599631
67
General Esm H240
Price Tag%201security advisorycriticaldata integrity

Linux Security Advisory: Critical DoS Threat with Encrypted Loop Devices

The following text describes a security hole in the encrypted loop device for linux. Because of it, an attacker is able to modify the content of the encrypted device without being detected. This text proposes to fix the hole by authenticating the device.. . . . The following text describes a security hole in the encrypted loop device for linux. Because of it, an attacker is able to modify the content of the encrypted device without being detected. This text proposes to fix the hole by authenticating the device. Vulnerability in encrypted loop device for Linux Jerome Etienne This email address is being protected from spambots. You need JavaScript enabled to view it. Abstract This text describes a security hole i found in encrypted loop device for Linux. An attacker is able to modify the content of the encrypted device without being detected (see section 2 ). This text proposes to fix the hole by authenticating the device (see section 3 ). 1 Threat model Encrypting a disk device aims to protect against a off-line attacker who would be able to access the disk between 2 legitimate mounts. It isn't against an attacker who has access to the running computer when the encrypted device is mounted as either (i) the attacker is root and it can access the encrypted device anyway or (ii) he is an unprivileged user and can be stopped with Unix's right management (i.e. user/group). 2 Attack description The vulnerability of encrypted loop device is due to its lack of authentication. The aim of encryption is to make the data unreadable for anybody who doesn't know the key. It doesn't prevent an attacker from modifying the data. People assume that an attacker won't do it because the attacker wouldn't be able to choose the resulting clear text. But this section shows that the attacker can choose the resulting clear text to some extends and that modifying the cypher text data may be interesting even if the attacker ignores the result. This attack is only applicable to device storing data which are reused across mounts: most file-system(e.g. ext2, reiserfs, ext3) but not swap. In some systems, encrypted device are stored in the same location than the encrypted disk containing the operating system. For those systems the attacker who can access the encrypted device, can easily modify the OS to gain access (e.g. kernel) independtly of the encrypted device. 2.1 To insert random data If the attacker modifies the cipher text without choosing the resulting clear text, it will likely produce random data. The legitimate user won't detect the modification and will use them as if they were valid. As they likely appears random, it will result of a Denial of Service (aka DoS). 2.2 To insert chosen data The encryption mode used by encrypted loop device is CBC[ oST81 ,sec 5.3]. CBC allows cut/past attacks i.e. the attacker can cut encrypted data from one part of the device and paste them in another location. As both data sections have been encrypted by the same key, the clear text won't be completely random data. This lack of authentication isn't a CBC flaw. Authentication isn't considered a aim of the encryption mode, so most modes (e.g. ECB, CFB, OFB) doesn't authenticate the data. To use another mode would be flawed in the same way except if they explicitly protect against forgery. Recently some modes including authentication popped up to speed up the encryption / authentication couple but as far as i know they are all patented. In very short, encrypting with CBC is Cn=Enc(Cn-1 xor Pn) where Enc(x) is encrypting x, Pn is the nth block of plain text and Cn the nth block of cipher text. For the first block, Cn-1 is an Initial vector (aka IV) which may be public and must be unique for a given key. The decryption is Pn = Dec(Cn) xor Cn-1. See [ oST81 ,sec 5.3] for a longer description of CBC. If the attacker copies s blocks from the location m to n (aka [Cn,...,Cn+s-1] == [Cm,...,Cm+s-1]), Pn+1 up to Pn+s-1 will the same as Pm+1 to Pm+s-1 and Pn will likely appears random. Cn (i.e. Cm) will be decrypted as Pn = Dec(Cm)xor Cn-1 but Cm-1 and Cn-1 are different so Pn will likely appears random. Nevertheless Pn+1 = Dec(Cn+1) xor Cn = Dec(Cm+1) xor Cm = Pm+1, so Pn+1=Pm+1. So if the attacker has an idea of the content of a group of blocks in the device, he can copy them to the Nth block, thus it can choose the content of it without being detected. As an file-system isn't designed to appears random, its content may be predictable to some extents (e.g. common directories and files, inode, superblock). The attacker may use such informations to guess the contents and do a knowledgeable cut/past. For example, an attacker knowing the location of a password file may replace a password by another one which is already known. 3 Proposed fixes We propose 2 types of fixes: one which authenticate at mount time (see section 3.1 ) and the other which authenticates at the cluster level (see section 3.2 ). The choice between the two (see section 3.4 ) is a user matter as it mostly depends on the access pattern on the encrypted device. In the proposed fixes, the authentication is a MAC computed over the encrypted device. The MAC is HMAC[ KBC97 ] combined with a configured hash function, preferably a well studied one such as SHA1[ oST95 ] or MD5[ Riv92 ]. The MAC secret key is derived from the pass-phrase via PKCS-5 key derivations ([ Kal00 ,sec 5.1]). 3.1 Authenticating at mount time As we need to authenticate the device across mounts and not while it is mounted (see section 1 ), it is sufficient to authenticate the whole device during mount operations. It slows down mount operations but they are rather infrequent so we consider the trade-off delay/security acceptable. The MAC is verified during mount operations and generated during unmount operations. It isn't supposed to be valid while the device is mounted. The MAC generation is done when unmounting the device. The MAC is computed over all the sectors of the device and the result is appended in the device file after all the sectors. The MACverification is done when mounting the device. The MAC is computed over all the sectors of the device. If the result is equal to the MAC appended to the block device, the verification succeed, else it failed. The verification may fail (i) if an attacker attempted to modify the device during 2 legitimates mounts or (ii) if the device hasn't been cleanly unmounted (e.g. computer crash). It is impossible to automatically distinguish both cases with certainty. So if the verification fails, the user is notified and the mount operation may be stopped depending on configuration. 3.2 Authenticating at cluster level To authenticate the whole device at mount time, may be considered prohibitive by some users, so this section describe an alternative which authenticate the device at the cluster level. A cluster is a group of one or more sectors, the exact number depends on configuration. In this case, the MAC is verified each time a cluster is read from the disk and generated at each write. If the device isn't cleanly unmounted, the authentication of one or more cluster may fail (e.g. the super block). This case will be detected at mount time. But if an attacker forges data in the device, it will be detected only when the user read the modified data. The kernel will read the forged cluster and the authentication will fail. It may report it with a printk with a rate limitor, it isn't clean but i don't see any better way. 3.3 MAC location Currently the encrypted loop file-system is stored in a regular file of a hosting file-system. Its size is a multiple of a sector size (i.e. 512 byte). The MAC could be stored in a separate file or included in the regular file. To store the MAC in a separate file, generates problems while managing the loop device file (e.g. copy, backup). The administrator must not forget to copy the MAC file when he copies the device file, else the copied device won't be usable anymore. To store the MAC in the same file as the clusters doesn't has this disadvantage. 3.4 Comparison To authenticate at the cluster level will increase the access time of each cluster but won't affect mount operation. The exact increase depends on the MAC and encryption algorithms. As a rule of thumb, MAC algorithms are typically 3 times faster than encryption ones so the time dedicated to cryptography for each block will increase by around 30%. To authenticate at mount time will largely slow down the mount operations but won't affect every access once mounted. The authentication at mount time will detect forgery at mount time, whereas the alternative detects it only when the forged cluster is read, possibly a long time after the modification. Users may consider that it is easier to diagnose who forged it if they have a better idea of when the attack occurred. To authenticate the whole device at mount time requires a single MAC per device, so the space overhead (typically 16 byte) is negligible compared to the device's size. To authenticate at the cluster level requires a MAC per cluster, it is significantly more but some people may consider it still negligible, especially with cheap disks. The choice between the two mostly depends on the access pattern on the encrypted device. If the device is used for interactive purpose, the increased access latency may be unsuitable. If the access latency is important or if every block is frequently modified, to authenticate only once at mount time may be more interesting. If the user can't stand long mount operations, to authenticate at cluster level will be more suitable. As only the final user knows the type access made on his encrypted device, he should be the one able to choose between the two. 4 Acknowledgments Thanks to Andy Kleen and Phil Swan for their useful comments. 5 Conclusion This text described an vulnerability in encrypted loop device which allows an attacker to modify the encrypted device without being detected (see section 2 ). We propose a fix which authenticate the whole device during mountoperation (see section 3.1 ). This fix slows down mount operations but we consider the trade-off longer delay vs additional security very reasonable as mount operations are rather infrequent. We propose another fix which authenticate at cluster level for people who can't stand long mount operation. The choice between the two is a final user matter. The authentication may be optionally disabled thus if an user considers the trade-off delay/security not in favor of security, he may choose to be vulnerable to this attack and disable it. Nevertheless the author thinks encrypted loop device must be secure by default. References [Kal00] B. Kaliski. Pkcs 5: Password-based cryptography specification version 2.0. Request For Comment (Informational) RFC2898 , September 2000. [KBC97] H. Krawczyk, M. Bellare, and R. Canetti. Hmac: Keyed-hashing for message authentication. Request For Comment (Informational) RFC2104 , February 1997. [oST81] National Institute of Standards and Technology. implementing and using the nbs data encryption standard. Federal information processing standards fips74 , April 1981. [oST95] National Institute of Standards and Technology. Secure hash standard. Federal information processing standards fips180-1 , April 1995. [Riv92] R. Rivest. The md5 message-digest algorithm. Request For Comment (Informational) RFC1321 , April 1992. . The following text describes a security hole in the encrypted loop device for linux. Because of it, . describes, security, encrypted, device, linux, because. . LinuxSecurity.com Team

Calendar%202 Nov 02, 2023 •User Avatar LinuxSecurity.com Team Cryptography
77
4.Lock AbstractDigital Esm H240
Price Tag%201open source toolsattack preventionserver protection

Uncover Open Source Instruments For Securing Your Linux Servers

While Linux does have a variety of security features to help make it safer, it’s not impenetrable, which is why you need open-source tools to secure your Linux server. . You need the right software to sniff out potential attacks and vulnerabilities. On its own Linux isn’t going to keep your server safe. It’s the other security measures you take. Luckily, open-source tools make this job easier. . Uncover vital open-source resources to proficiently safeguard your Linux server from imminent threats and weaknesses.. Open Source Security Tools, Linux Server Security, Cybersecurity Applications. . LinuxSecurity.com Team

Calendar%202 Dec 14, 2022 •User Avatar LinuxSecurity.com Team Server Security
Banner 2 1028x280 1708121730 1 1771599631
210
Rhel Esm H240
Price Tag%201security advisorysecurity issuekernel update

CentOS 7 and RHEL 7 Important Kernel Update: 11 Critical Fixes

CentOS Linux 7 and Red Hat Enterprise Linux (RHEL) 7 are vulnerable to over a dozen kernel bugs. Red Hat has issued an important security update mutigating these flaws - patch now! . The new kernel security and bug fix update has been rated by Red Hat Product Security as having a security impact of ‘Important’ and affects the kernel packages in all supported Red Hat Enterprise Linux 7 operating system editions, as well as the CentOS Linux 7 operating system series. The update addresses 11 security vulnerabilities, including CVE-2020-25705, a flaw discovered in the ICMP global rate limiter that could allow an off-path remote attacker to bypass source port UDP randomization and facilitate attacks on UDP based services that depend on source port randomization. The link for this article located at 9 to 5 Linux is no longer available. . Crucial kernel security patch for CentOS 7 and RHEL 7 addresses 11 vulnerabilities categorized as critical by Red Hat. Take action immediately!. Kernel Security Update, CentOS 7, RHEL 7, Bug Fixes, Red Hat Update. . Brittany Day

Calendar%202 Mar 23, 2021 •User Avatar Brittany Day Security Vulnerabilities
83
32.Lock Code Circular Esm H240
Price Tag%201security measuresopen sourceattack prevention

How To Prevent SolarWinds-Style Attacks Using Linux Foundation Guidance

The Linux Foundation has offered suggestions on how we can avoid SolarWinds type attacks in the future. Doing so won't be easy - but it must be done. . One of the most irritating things about the SolarWinds attack was that the Russian crack went unnoticed from March to December 2020. During that time, the Russian government's SolarWinds hack was opening the door to the secrets of numerous top American government agencies and tech companies. Even now, we're still trying to get our minds around just how widespread and bad the SolarWinds cracks were. The root causes of this crack were a dangerous set of software supply-chain failures. It's too late for anything but damage control for SolarWinds, but The Linux Foundation has found several lessons to make sure your programs, whether open source or proprietary, avoid SolarWinds-style disasters. . To prevent threats like SolarWinds, prioritize a multi-layered security strategy with software integrity, community support, and vigilant monitoring techniques. SolarWinds Defense, Linux Foundation Insights, Open Source Security. . LinuxSecurity.com Team

Calendar%202 Jan 15, 2021 •User Avatar LinuxSecurity.com Team Hacks/Cracks
Banner 2 1028x280 1708121730 1 1771599631
67
24.Key Code Esm H240
Price Tag%201network securitysecurity practiceskey management

Mastering SSH Key Management for Enhanced Network Security

SSH keys play a critical role in server and network security, yet are too often overlooked by admins, IT professionals and security teams. . SSH keys are everywhere. However, despite their widespread use and high-privilege access, they’re often overlooked by IT and security teams. Meanwhile, malicious actors seek to exploit unmanaged and unprotected keys to perform SSH attacks and spread through networks undetected. In this blog, we’ll discuss the underlying problem of SSH key sprawl and how to prevent emerging SSH attacks, such as FritzFrog and Lemon_Duck, by implementing proper key management and security practices. The link for this article located at Security Boulevard is no longer available. . API tokens, frequently disregarded, facilitate major breaches. Discover how to secure tokens and strengthen defenses against vulnerabilities.. SSH Key Management, Network Security, Attack Prevention. . LinuxSecurity.com Team

Calendar%202 Sep 16, 2020 •User Avatar LinuxSecurity.com Team Cryptography
82
General Esm H240
Price Tag%201cyber defensenational securityattack prevention

NCSC Reports Tackling 10 Cyber Attacks Weekly Since Year 2016

The UK’s National Cyber Security Centre (NCSC) has blocked more than 10 cyber-attacks per week in its first two years of operation, blaming nation states for the majority of incidents.. The government body was spun out of GCHQ in 2016 with a goal of making the UK one of the safest places to live and work online. The link for this article located at InfoSecurity is no longer available. . The government body was spun out of GCHQ in 2016 with a goal of making the UK one of the safest plac. national, cyber, security, centre, (ncsc), blocked, cyber-attacks. . Brittany Day

Calendar%202 Oct 17, 2018 •User Avatar Brittany Day Government
Banner 2 1028x280 1708121730 1 1771599631
News Add Esm H340

Get the latest News and Insights

Get the latest Linux and open source security news straight to your inbox.

Community Poll

More Polls

Should Linux servers automatically install security updates?

No answer selected. Please try again.
Please select either existing option or enter your own, however not both.
Please select minimum {0} answer(s).
Please select maximum {0} answer(s).
/main-polls/157-should-linux-servers-automatically-install-security-updates?task=poll.vote&format=json
157
radio
0
[{"id":506,"title":"Yes \u2014 critical security patches should install automatically.","votes":0,"type":"x","order":1,"pct":0,"resources":[]},{"id":507,"title":"No \u2014 every update should be tested before deployment.","votes":0,"type":"x","order":2,"pct":0,"resources":[]},{"id":508,"title":"Only critical vulnerabilities should auto-install.","votes":0,"type":"x","order":3,"pct":0,"resources":[]},{"id":509,"title":"I patch when Reddit starts panicking.","votes":0,"type":"x","order":4,"pct":0,"resources":[]}] ["#ff5b00","#4ac0f2","#b80028","#eef66c","#60bb22","#b96a9a","#62c2cc"] ["rgba(255,91,0,0.7)","rgba(74,192,242,0.7)","rgba(184,0,40,0.7)","rgba(238,246,108,0.7)","rgba(96,187,34,0.7)","rgba(185,106,154,0.7)","rgba(98,194,204,0.7)"] 350
bottom 200

Search Topics