[{"data":1,"prerenderedAt":176},["ShallowReactive",2],{"publication:en:P184":3},{"meta":4,"copy":17,"relatedArticles":136,"terms":168,"term":169,"resourceParent":170,"glossaryParent":173},{"id":5,"path":6,"kind":7,"keyword":8,"title":9,"seoTitle":10,"description":11,"incoming":12,"updated":15,"preparedOn":16},"P184","\u002Fblog\u002Flinux-server-hardening","article","Linux server hardening for small business","Linux server hardening for small business: an owned baseline","Linux server hardening for a small business","Plan Linux server hardening around access, updates, exposed services and recovery. Record each control, owner, exception and functional acceptance check.",[13,14],"\u002Fservices\u002Flinux-vps","\u002Fservices\u002Fsecurity-audit","2026-08-01","2026-10-30",{"intro":18,"sections":19,"checklist":92,"faq":98,"links":108,"sources":128,"cta":131},"Linux server hardening for a small business should begin with an owned baseline: required services, administrative access, supported updates, network exposure and recovery. Record what each control protects, who maintains it and how the business function will be checked after a change. A hardened label or completed checklist is not proof of complete security, incident cleanup or a managed service beyond the agreed scope.",[20,29,65,74,82,87],{"title":21,"paragraphs":22,"sources":25},"Establish the starting state and the responsibility boundary",[23,24],"List the server's business role, operating-system release, applications, providers and people who can administer it. Separate the hosting account, guest operating system and application responsibilities. If a supplier manages part of the environment, obtain the actual scope instead of assuming that access to a control panel includes security maintenance for everything beneath it.","NIST's hardening definition connects reduced attack opportunities with patching and nonessential-service reduction. Applying that idea requires a business decision about what the server needs. A web process, database, backup agent and integration may have different access requirements. Identify those dependencies before removing services or restricting traffic so the accepted result can preserve necessary work through a deliberately chosen path.",[26],{"label":27,"url":28},"NIST glossary: hardening and source context","https:\u002F\u002Fcsrc.nist.gov\u002Fglossary\u002Fterm\u002Fhardening",{"title":30,"paragraphs":31,"table":34},"Build a baseline that links controls to acceptance",[32,33],"Use the baseline below to connect a proposed restriction to an owner and a test. This is an original planning framework, not a formal benchmark assessment or a claim of certification. Record the actual configuration and the reason it was accepted. If a control cannot be applied because of a dependency, state the exception and who will revisit it instead of silently marking the item complete.","Keep the record concise enough to maintain after handoff. A backup schedule, open port or administrative account should have a business purpose and an accountable owner. Acceptance needs to cover both the restriction and the required function. For example, a maintenance connection should still work through the approved route, rather than only disappear from the location used for an initial check.",{"caption":35,"headers":36,"rows":40},"Linux control, owner and acceptance baseline",[37,38,39],"Area","Decision to record","Acceptance evidence",[41,45,49,53,57,61],[42,43,44],"Support and updates","Release, supported components and update owner.","Deployed state and update results are reviewed.",[46,47,48],"Administration","Named users, keys, privileges and approved path.","Fresh authorized connection and required task work.",[50,51,52],"Services and traffic","Required listeners and inbound\u002Foutbound flows.","Intended functions work; scoped unwanted paths are restricted.",[54,55,56],"Application and secrets","Process permissions and credential ownership.","Required integration works without unnecessary access.",[58,59,60],"Recovery","Restore source, access and provider dependencies.","A controlled recovery check has an accepted result.",[62,63,64],"Exceptions","Reason, approver and review trigger.","The limitation remains visible and owned.",{"title":66,"paragraphs":67,"sources":70},"Keep updates under a working maintenance process",[68,69],"An update setting needs a person who checks its results and handles failures. Ubuntu documents automatic-update configuration and operational considerations; use the current guidance for the actual distribution and release. Do not assume that every repository, application or third-party package is covered by the same mechanism. Record the components included and any separate supplier update route.","Plan service restarts, business checks and recovery around the actual workload. A package installation result is not the same as acceptance that a checkout, notification or integration still works. Conversely, postponing every update indefinitely is not a maintenance plan. Establish who assesses urgency, authorizes the change and verifies the outcome without inventing a universal schedule or a response promise that the business has not agreed.",[71],{"label":72,"url":73},"Ubuntu Server: automatic updates and their configuration","https:\u002F\u002Fubuntu.com\u002Fserver\u002Fdocs\u002Fhow-to\u002Fsoftware\u002Fautomatic-updates\u002F",{"title":75,"paragraphs":76,"example":79},"Review access and exposure along the actual path",[77,78],"Check account ownership, administrative privileges and the routes used for maintenance. A shared key with no named owner can make later revocation difficult. Coordinate changes with the suppliers who still need legitimate access and prepare recovery before restricting the current route. An old SSH session remaining open does not establish that a replacement administrator can connect after the change.","Review provider controls, host filtering and container publishing as separate enforcement points where they exist. The public website and a private database do not need identical exposure. Include required outbound flows, such as backups and approved integrations. Verify only within authorized scope and describe which paths were checked. A dashboard's enabled flag is not evidence that every traffic route matches the intended baseline.",{"title":80,"text":81},"Illustrative example: the update works, the integration does not","A fictional server completes an operating-system update, but a controlled business check finds that a required external integration no longer connects. The team records the failed acceptance, reviews the relevant change and uses its approved recovery route. It does not declare the whole task complete from the package status. This is a proposed scenario, not a server test or customer outcome.",{"title":83,"paragraphs":84},"Prepare recovery and useful operational evidence",[85,86],"Identify who can access the hosting console, retrieve a restore source and re-establish the application if the server becomes unavailable. A provider snapshot and an application-consistent recovery can have different scope. Agree which data state is acceptable and what would be lost at the selected recovery point. Use controlled restoration checks rather than assuming a successful backup job proves recoverability.","Define the observations needed to maintain the baseline, such as update failures, administrative changes and service errors, with an owner for relevant follow-up. Keep evidence access and retention proportionate to the business and system. Do not label a collection of unattended logs as continuous monitoring. The handoff should distinguish the controls actually implemented from provider dependencies and specialist work outside the task.",{"title":88,"paragraphs":89},"Hand over changes, exceptions and the next review trigger",[90,91],"Summarize the starting state, accepted configuration, checks performed and remaining limits. Name the person responsible for new accounts, package changes and integrations after the task. A useful review trigger can be a new deployment, migration or supplier departure. This keeps the baseline connected to real changes instead of leaving the owner with a checklist that becomes inaccurate immediately after handoff.","CyberFixCrew is an Israeli cybersecurity company serving businesses worldwide with practical Israeli Linux, website and digital-infrastructure knowledge. We can discuss the scoped technical work described on this site. No certification, managed SOC, fixed incident response time or complete security guarantee is implied. Describe the server's role and concern first so authority, access, acceptance and maintenance responsibilities can be agreed.",[93,94,95,96,97],"Record the server’s role, release and responsibility boundary.","Assign an owner and acceptance check to each control.","Review actual update coverage and operational results.","Prepare recovery before access and network changes.","Hand over exceptions, tested functions and future review triggers.",[99,102,105],{"question":100,"answer":101},"Is there one Linux hardening configuration for every server?","No, the required services, distribution, provider controls and recovery arrangements differ. Build an accepted baseline for the actual workload.",{"question":103,"answer":104},"Do automatic updates cover every application?","Do not assume so: review the configured update mechanism and separately owned repositories, applications and supplier components.",{"question":106,"answer":107},"Does a hardened server prove a previous incident is resolved?","No, configuration work, incident evidence, access remediation and trusted recovery need separate scope and acceptance.",[109,112,115,118,121,123,125],{"path":110,"label":111},"\u002Fglossary\u002Fhardening","Understand hardening and baseline ownership",{"path":113,"label":114},"\u002Fblog\u002Flinux-ssh-hardening","Plan and verify SSH access changes",{"path":116,"label":117},"\u002Fblog\u002Fdocker-security-checklist","Review container boundaries on the host",{"path":119,"label":120},"\u002Fblog\u002Fhosting-security-responsibility","Clarify provider and customer responsibility",{"path":13,"label":122},"Scope Linux and VPS technical work",{"path":14,"label":124},"Agree an authorized configuration review",{"path":126,"label":127},"\u002Fblog\u002Fsmall-business-asset-inventory","Map the assets and owners behind the server baseline",[129,130],{"label":27,"url":28},{"label":72,"url":73},{"title":132,"description":133,"button":134,"type":135},"Build a server baseline around the actual workload","Describe the server role, provider and main concern without sending root credentials or private configuration exports.","Discuss the Linux hardening scope","check",[137,145,153,160],{"id":138,"path":113,"title":139,"description":140,"category":141,"artwork":142,"order":143,"publishedOn":144},"P101","SSH hardening for Linux servers without losing authorized access","Review SSH users, keys, privileges and network exposure. Plan recovery access, syntax checks and fresh-session tests before retiring the old access route.","infrastructure","servers",42,"2026-07-18",{"id":146,"path":147,"title":148,"description":149,"category":141,"artwork":150,"order":151,"publishedOn":152},"P082","\u002Fblog\u002Fhttp-security-score-limits","Does an A+ security headers score mean your website is secure?","Read security scan grades with their URL, test scope and limitations. Turn findings into verified fixes without confusing a header score with a full audit.","security-diagnostics",55,"2026-08-17",{"id":154,"path":116,"title":155,"description":156,"category":141,"artwork":157,"order":158,"publishedOn":159},"P187","Docker security checklist for small business: verify the boundaries","Review Docker daemon access, users, mounts, published ports, images and recovery. Separate container configuration from host and application security.","integrations",35,"2026-07-02",{"id":161,"path":162,"title":163,"description":164,"category":141,"artwork":165,"order":166,"publishedOn":167},"P081","\u002Fblog\u002Fsecurity-headers-explained","HTTP security headers for business websites: choose, test and maintain","Choose security headers by browser behavior and website dependencies. Plan CSP, HSTS, framing and content-type changes with safe rollout and business checks.","security",62,"2026-08-31",[],null,{"path":171,"label":172},"\u002Fresources","Website security resources and templates",{"path":174,"label":175},"\u002Fglossary","Cybersecurity glossary for small businesses",1794134059208]