{"id":82504,"date":"2026-03-05T10:59:56","date_gmt":"2026-03-05T15:59:56","guid":{"rendered":"https:\/\/www.inmotionhosting.com\/blog\/?p=82504"},"modified":"2026-03-03T11:05:00","modified_gmt":"2026-03-03T16:05:00","slug":"server-hardening-best-practices-dedicated-servers","status":"publish","type":"post","link":"https:\/\/www.inmotionhosting.com\/blog\/server-hardening-best-practices-dedicated-servers\/","title":{"rendered":"Server Hardening Best Practices for Dedicated Servers"},"content":{"rendered":"\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"538\" src=\"https:\/\/www.inmotionhosting.com\/blog\/wp-content\/uploads\/2026\/03\/Server-Hardening-Best-Practices-for-Dedicated-Servers-1024x538.png\" alt=\"Server Hardening Best Practices for Dedicated Servers\" class=\"wp-image-82506\" srcset=\"https:\/\/www.inmotionhosting.com\/blog\/wp-content\/uploads\/2026\/03\/Server-Hardening-Best-Practices-for-Dedicated-Servers-1024x538.png 1024w, https:\/\/www.inmotionhosting.com\/blog\/wp-content\/uploads\/2026\/03\/Server-Hardening-Best-Practices-for-Dedicated-Servers-300x158.png 300w, https:\/\/www.inmotionhosting.com\/blog\/wp-content\/uploads\/2026\/03\/Server-Hardening-Best-Practices-for-Dedicated-Servers-768x403.png 768w, https:\/\/www.inmotionhosting.com\/blog\/wp-content\/uploads\/2026\/03\/Server-Hardening-Best-Practices-for-Dedicated-Servers.png 1200w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n<div class=\"wp-block-post-excerpt\"><p class=\"wp-block-post-excerpt__excerpt\">A freshly provisioned dedicated server is not a secure server. Default configurations are designed for broad compatibility, not minimal attack surface. Every open port that shouldn&#8217;t be open, every default credential that wasn&#8217;t changed, every world-readable file with sensitive content is an exposure waiting to be discovered.Server hardening is the process of reducing that attack&hellip; <\/p><\/div>\n\n\n<h2 class=\"wp-block-heading\"><strong>Start with the Attack Surface Inventory<\/strong><\/h2>\n\n\n\n<p>Before changing anything, know what&#8217;s running:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># All listening ports\n\nss -tlnp\n\n# Running services\n\nsystemctl list-units --type=service --state=running\n\n# SUID\/SGID files (privilege escalation candidates)\n\nfind \/ -perm \/6000 -type f 2>\/dev\/null\n\n# World-writable directories\n\nfind \/ -xdev -type d -perm -0002 2>\/dev\/null<\/code><\/pre>\n\n\n\n<p><\/p>\n\n\n\n<p>Document what each open port and running service is for. If you can&#8217;t immediately answer &#8220;why is this port open,&#8221; that&#8217;s the first thing to investigate.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>SSH Hardening<\/strong><\/h2>\n\n\n\n<p>SSH is the primary administrative access vector on Linux servers \u2014 and the primary target for brute-force attacks. Hardening SSH closes off the most common attack path before any other configuration.<\/p>\n\n\n\n<p>Edit \/etc\/ssh\/sshd_config and enforce these settings:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Disable password authentication entirely\n\nPasswordAuthentication no\n\nChallengeResponseAuthentication no\n\n# Disable root login over SSH\n\nPermitRootLogin no\n\n# Use a non-standard port (reduces automated scan noise)\n\nPort 2222\n\n# Limit SSH to specific users\n\nAllowUsers deploy_user admin_user\n\n# Reduce authentication timeout window\n\nLoginGraceTime 30\n\nMaxAuthTries 3\n\n# Disable legacy protocol features\n\nProtocol 2\n\nX11Forwarding no\n\nAllowAgentForwarding no\n\nAllowTcpForwarding no\n\n# Keep-alive settings to terminate idle sessions\n\nClientAliveInterval 300\n\nClientAliveCountMax 2<\/code><\/pre>\n\n\n\n<p>Key-based authentication is mandatory once password authentication is disabled. Generate keys on your local machine with ssh-keygen -t ed25519 and copy the public key to ~\/.ssh\/authorized_keys on the server before disabling passwords.<\/p>\n\n\n\n<p>Apply the changes: systemctl restart sshd. Verify you can still connect via key before closing your current session.<\/p>\n\n\n\n<p><a href=\"https:\/\/csrc.nist.gov\/publications\/detail\/sp\/800-123\/final\">NIST Special Publication 800-123<\/a> provides comprehensive guidance on SSH configuration in production environments, including key management practices.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Firewall Configuration with nftables<\/strong><\/h2>\n\n\n\n<p>Modern Linux distributions use nftables as the preferred firewall framework. A minimal ruleset for a web server:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>#!\/usr\/sbin\/nft -f\n\nflush ruleset\n\ntable inet filter {\n\n\u00a0\u00a0\u00a0\u00a0chain input {\n\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0type filter hook input priority 0; policy drop;\n\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0# Accept established\/related connections\n\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0ct state established,related accept\n\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0# Accept loopback\n\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0iif lo accept\n\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0# Accept ICMP (ping) - limit rate\n\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0icmp type echo-request limit rate 5\/second accept\n\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0icmpv6 type echo-request limit rate 5\/second accept\n\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0# SSH on custom port\n\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0tcp dport 2222 ct state new limit rate 10\/minute accept\n\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0# HTTP and HTTPS\n\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0tcp dport { 80, 443 } accept\n\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0# Log and drop everything else\n\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0log prefix \"Dropped: \" drop\n\n\u00a0\u00a0\u00a0\u00a0}\n\n\u00a0\u00a0\u00a0\u00a0chain forward {\n\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0type filter hook forward priority 0; policy drop;\n\n\u00a0\u00a0\u00a0\u00a0}\n\n\u00a0\u00a0\u00a0\u00a0chain output {\n\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0type filter hook output priority 0; policy accept;\n\n\u00a0\u00a0\u00a0\u00a0}\n\n}<\/code><\/pre>\n\n\n\n<p>Save to \/etc\/nftables.conf and enable: systemctl enable &#8211;now nftables. The default policy is drop on inbound \u2014 only explicitly allowed traffic gets through.<\/p>\n\n\n\n<p>For servers running cPanel\/WHM, cPanel manages its own firewall rules. Use ConfigServer Security &amp; Firewall (CSF), which integrates with WHM and provides a UI for rule management without overriding cPanel&#8217;s required ports.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>User Account Management<\/strong><\/h2>\n\n\n\n<p>Every user account is a potential compromise vector. Dedicate attention to:<\/p>\n\n\n\n<p><strong>Disable unused system accounts<\/strong>: Check \/etc\/passwd for accounts with login shells that shouldn&#8217;t have them. Set their shell to \/sbin\/nologin:<\/p>\n\n\n\n<p>usermod -s \/sbin\/nologin unused_account<\/p>\n\n\n\n<p><strong>Remove unnecessary sudo privileges<\/strong>: visudo to review \/etc\/sudoers. Each line granting NOPASSWD sudo is a privilege escalation path if that account is compromised. Require password for all sudo operations in production.<\/p>\n\n\n\n<p><strong>Use role-based user accounts<\/strong>: Application services should run as their own dedicated system user with minimal permissions. The web server shouldn&#8217;t run as root. MySQL shouldn&#8217;t run as root. Create application-specific users:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>useradd -r -s \/sbin\/nologin -d \/var\/www\/app appuser\n\nchown -R appuser:appuser \/var\/www\/app<\/code><\/pre>\n\n\n\n<p><strong>Audit last logins regularly<\/strong>: lastlog | grep -v Never shows accounts that have been used to log in. Accounts you didn&#8217;t expect to see in that output warrant investigation.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Kernel Hardening via sysctl<\/strong><\/h2>\n\n\n\n<p>Several kernel parameters reduce the attack surface for network-level exploits:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># \/etc\/sysctl.d\/99-hardening.conf\n\n# Disable IP source routing (used in some spoofing attacks)\n\nnet.ipv4.conf.all.accept_source_route = 0\n\nnet.ipv4.conf.default.accept_source_route = 0\n\n# Disable ICMP redirect acceptance\n\nnet.ipv4.conf.all.accept_redirects = 0\n\nnet.ipv4.conf.default.accept_redirects = 0\n\n# Enable reverse path filtering (anti-spoofing)\n\nnet.ipv4.conf.all.rp_filter = 1\n\n# Disable ping broadcasts\n\nnet.ipv4.icmp_echo_ignore_broadcasts = 1\n\n# Log martian packets (packets with impossible source addresses)\n\nnet.ipv4.conf.all.log_martians = 1\n\n# Disable IPv6 if not in use\n\nnet.ipv6.conf.all.disable_ipv6 = 1\n\n# Kernel pointer hiding\n\nkernel.kptr_restrict = 2\n\nkernel.dmesg_restrict = 1<\/code><\/pre>\n\n\n\n<p>Apply with sysctl -p \/etc\/sysctl.d\/99-hardening.conf.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>File System Security<\/strong><\/h2>\n\n\n\n<p><strong>Set correct permissions on sensitive directories:<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>chmod 750 \/root\n\nchmod 644 \/etc\/passwd\n\nchmod 640 \/etc\/shadow\n\nchmod 600 \/etc\/ssh\/sshd_config<\/code><\/pre>\n\n\n\n<p><strong>Mount options that reduce privilege escalation risks<\/strong>:<\/p>\n\n\n\n<p>Edit \/etc\/fstab to add noexec, nosuid, and nodev to partitions that shouldn&#8217;t contain executable files:<\/p>\n\n\n\n<p>\/dev\/sdb1 \/var\/tmp ext4 defaults,noexec,nosuid,nodev 0 2<\/p>\n\n\n\n<p><strong>Audit file integrity with AIDE<\/strong>: <a href=\"https:\/\/aide.github.io\/\">AIDE (Advanced Intrusion Detection Environment)<\/a> creates a database of file checksums and can alert when files change unexpectedly. Initialize with aide &#8211;init, then run aide &#8211;check periodically or via cron. Unexpected changes to system binaries, libraries, or configuration files indicate a compromise.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Software and Package Management<\/strong><\/h2>\n\n\n\n<p><strong>Keep packages current<\/strong>: Unpatched vulnerabilities in the kernel, OpenSSL, glibc, and other system libraries are the most common path to server compromise after weak credentials.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># CentOS\/AlmaLinux\/Rocky Linux\n\ndnf update --security -y\n\n# Ubuntu\/Debian\n\napt-get upgrade -y<\/code><\/pre>\n\n\n\n<p>Automate security updates: dnf-automatic (RHEL family) or unattended-upgrades (Debian family) can be configured to automatically apply security patches while leaving major version upgrades for manual review.<\/p>\n\n\n\n<p><strong>Audit installed packages<\/strong>: Remove packages that were installed for testing and never removed. Each installed package is a potential vulnerability. rpm -qa (RHEL) or dpkg -l (Debian) lists everything installed.<\/p>\n\n\n\n<p><strong>Remove development tools from production servers<\/strong>: Compilers, debuggers, and package build tools don&#8217;t belong on production servers. An attacker who gains limited access can use them to compile exploit code. Remove gcc, make, and similar tools if they&#8217;re present.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Intrusion Detection and Log Monitoring<\/strong><\/h2>\n\n\n\n<p><strong>Fail2Ban<\/strong> monitors log files and blocks IPs that exhibit suspicious patterns \u2014 repeated failed SSH logins, Nginx 4xx error floods, and other abuse signals. <a href=\"https:\/\/www.fail2ban.org\/wiki\/index.php\/MANUAL_0_8\">Fail2Ban<\/a> is installable via the package manager on all major Linux distributions and works with any log file format.<\/p>\n\n\n\n<p><strong>Log centralization<\/strong>: Shipping logs to a remote syslog server means that even if the server is compromised and local logs are wiped, you retain the audit trail. rsyslog supports remote logging natively. For teams already running an ELK stack (Elasticsearch, Logstash, Kibana) or a managed log aggregation service, configure the server&#8217;s rsyslog.conf to forward to the central receiver.<\/p>\n\n\n\n<p><strong>Monarx malware detection<\/strong>: InMotion&#8217;s Premier Care bundle includes <a href=\"https:\/\/monarx.com\/\">Monarx<\/a>, a file-scanning malware detection engine designed specifically for web hosting environments. Monarx detects web shell uploads, malicious PHP injections, and cryptocurrency miners \u2014 the most common malware targeting Linux servers in web hosting contexts. It runs at the kernel level without the performance impact of traditional antivirus solutions.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Scheduling Regular Audits<\/strong><\/h2>\n\n\n\n<p>Hardening at provisioning time degrades over time if not maintained. Set a quarterly review cycle covering:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Review open ports against current application requirements<\/li>\n\n\n\n<li>Audit user accounts and SSH authorized_keys for all users<\/li>\n\n\n\n<li>Check AIDE integrity database for unexpected file changes<\/li>\n\n\n\n<li>Review sudo grants and remove any that are no longer needed<\/li>\n\n\n\n<li>Apply any security patches that weren&#8217;t automatically applied<\/li>\n\n\n\n<li>Review Fail2Ban and firewall logs for attack pattern changes<\/li>\n<\/ul>\n\n\n\n<p>The servers with the cleanest security records aren&#8217;t the ones that got hardened once and forgotten. They&#8217;re the ones where someone checks the work on a schedule.<\/p>\n\n\n\n<p><strong>Related reading<\/strong>: <strong><a href=\"https:\/\/www.inmotionhosting.com\/blog\/ddos-attack-is-my-vps-protected\/\" type=\"post\" id=\"4456\">DDoS Protection Strategies for Dedicated Infrastructure<\/a><\/strong> | <strong><a href=\"https:\/\/www.inmotionhosting.com\/blog\/bare-metal-servers-improve-security\/\" type=\"post\" id=\"71426\">Zero Trust Security on Bare Metal<\/a><\/strong><\/p>\n\n\n\n<p><\/p>\n","protected":false},"excerpt":{"rendered":"<p>A freshly provisioned dedicated server is not a secure server. Default configurations are designed for broad compatibility, not minimal attack surface. Every open port that shouldn&#8217;t be open, every default credential that wasn&#8217;t changed, every world-readable file with sensitive content is an exposure waiting to be discovered.<br \/>Server hardening is the process of reducing that attack surface systematically. This isn&#8217;t a one-time task \u2014 it&#8217;s a baseline configuration that gets established at provisioning and maintained through updates and audits.<\/p>\n","protected":false},"author":116,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[355],"tags":[],"class_list":["post-82504","post","type-post","status-publish","format-standard","hentry","category-dedicated-server-hosting"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v27.2 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Server Hardening Best Practices for Dedicated Servers | InMotion Hosting<\/title>\n<meta name=\"description\" content=\"OS-level security and firewall configuration for dedicated servers. Practical hardening steps covering SSH, firewall rules, user access, and kernel settings.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.inmotionhosting.com\/blog\/server-hardening-best-practices-dedicated-servers\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Server Hardening Best Practices for Dedicated Servers | InMotion Hosting\" \/>\n<meta property=\"og:description\" content=\"OS-level security and firewall configuration for dedicated servers. Practical hardening steps covering SSH, firewall rules, user access, and kernel settings.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.inmotionhosting.com\/blog\/server-hardening-best-practices-dedicated-servers\/\" \/>\n<meta property=\"og:site_name\" content=\"InMotion Hosting Blog\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/inmotionhosting\" \/>\n<meta property=\"article:published_time\" content=\"2026-03-05T15:59:56+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.inmotionhosting.com\/blog\/wp-content\/uploads\/2026\/03\/Server-Hardening-Best-Practices-for-Dedicated-Servers.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1200\" \/>\n\t<meta property=\"og:image:height\" content=\"630\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Sam Page\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@inmotionhosting\" \/>\n<meta name=\"twitter:site\" content=\"@inmotionhosting\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Sam Page\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"4 minutes\" \/>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Server Hardening Best Practices for Dedicated Servers | InMotion Hosting","description":"OS-level security and firewall configuration for dedicated servers. Practical hardening steps covering SSH, firewall rules, user access, and kernel settings.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.inmotionhosting.com\/blog\/server-hardening-best-practices-dedicated-servers\/","og_locale":"en_US","og_type":"article","og_title":"Server Hardening Best Practices for Dedicated Servers | InMotion Hosting","og_description":"OS-level security and firewall configuration for dedicated servers. Practical hardening steps covering SSH, firewall rules, user access, and kernel settings.","og_url":"https:\/\/www.inmotionhosting.com\/blog\/server-hardening-best-practices-dedicated-servers\/","og_site_name":"InMotion Hosting Blog","article_publisher":"https:\/\/www.facebook.com\/inmotionhosting","article_published_time":"2026-03-05T15:59:56+00:00","og_image":[{"width":1200,"height":630,"url":"https:\/\/www.inmotionhosting.com\/blog\/wp-content\/uploads\/2026\/03\/Server-Hardening-Best-Practices-for-Dedicated-Servers.png","type":"image\/png"}],"author":"Sam Page","twitter_card":"summary_large_image","twitter_creator":"@inmotionhosting","twitter_site":"@inmotionhosting","twitter_misc":{"Written by":"Sam Page","Est. reading time":"4 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"TechArticle","@id":"https:\/\/www.inmotionhosting.com\/blog\/server-hardening-best-practices-dedicated-servers\/#article","isPartOf":{"@id":"https:\/\/www.inmotionhosting.com\/blog\/server-hardening-best-practices-dedicated-servers\/"},"author":{"name":"Sam Page","@id":"https:\/\/www.inmotionhosting.com\/blog\/#\/schema\/person\/b459c4b748083c4f8431d5312e795796"},"headline":"Server Hardening Best Practices for Dedicated Servers","datePublished":"2026-03-05T15:59:56+00:00","mainEntityOfPage":{"@id":"https:\/\/www.inmotionhosting.com\/blog\/server-hardening-best-practices-dedicated-servers\/"},"wordCount":896,"commentCount":0,"publisher":{"@id":"https:\/\/www.inmotionhosting.com\/blog\/#organization"},"image":{"@id":"https:\/\/www.inmotionhosting.com\/blog\/server-hardening-best-practices-dedicated-servers\/#primaryimage"},"thumbnailUrl":"https:\/\/www.inmotionhosting.com\/blog\/wp-content\/uploads\/2026\/03\/Server-Hardening-Best-Practices-for-Dedicated-Servers-1024x538.png","articleSection":["Dedicated Server Articles"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.inmotionhosting.com\/blog\/server-hardening-best-practices-dedicated-servers\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.inmotionhosting.com\/blog\/server-hardening-best-practices-dedicated-servers\/","url":"https:\/\/www.inmotionhosting.com\/blog\/server-hardening-best-practices-dedicated-servers\/","name":"Server Hardening Best Practices for Dedicated Servers | InMotion Hosting","isPartOf":{"@id":"https:\/\/www.inmotionhosting.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.inmotionhosting.com\/blog\/server-hardening-best-practices-dedicated-servers\/#primaryimage"},"image":{"@id":"https:\/\/www.inmotionhosting.com\/blog\/server-hardening-best-practices-dedicated-servers\/#primaryimage"},"thumbnailUrl":"https:\/\/www.inmotionhosting.com\/blog\/wp-content\/uploads\/2026\/03\/Server-Hardening-Best-Practices-for-Dedicated-Servers-1024x538.png","datePublished":"2026-03-05T15:59:56+00:00","description":"OS-level security and firewall configuration for dedicated servers. Practical hardening steps covering SSH, firewall rules, user access, and kernel settings.","breadcrumb":{"@id":"https:\/\/www.inmotionhosting.com\/blog\/server-hardening-best-practices-dedicated-servers\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.inmotionhosting.com\/blog\/server-hardening-best-practices-dedicated-servers\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.inmotionhosting.com\/blog\/server-hardening-best-practices-dedicated-servers\/#primaryimage","url":"https:\/\/www.inmotionhosting.com\/blog\/wp-content\/uploads\/2026\/03\/Server-Hardening-Best-Practices-for-Dedicated-Servers.png","contentUrl":"https:\/\/www.inmotionhosting.com\/blog\/wp-content\/uploads\/2026\/03\/Server-Hardening-Best-Practices-for-Dedicated-Servers.png","width":1200,"height":630},{"@type":"BreadcrumbList","@id":"https:\/\/www.inmotionhosting.com\/blog\/server-hardening-best-practices-dedicated-servers\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.inmotionhosting.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Dedicated Server Articles","item":"https:\/\/www.inmotionhosting.com\/blog\/dedicated-server-hosting\/"},{"@type":"ListItem","position":3,"name":"Server Hardening Best Practices for Dedicated Servers"}]},{"@type":"WebSite","@id":"https:\/\/www.inmotionhosting.com\/blog\/#website","url":"https:\/\/www.inmotionhosting.com\/blog\/","name":"InMotion Hosting Blog","description":"Web Hosting Strategy, Trends and Security","publisher":{"@id":"https:\/\/www.inmotionhosting.com\/blog\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.inmotionhosting.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.inmotionhosting.com\/blog\/#organization","name":"InMotion Hosting","url":"https:\/\/www.inmotionhosting.com\/blog\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.inmotionhosting.com\/blog\/#\/schema\/logo\/image\/","url":"https:\/\/www.inmotionhosting.com\/blog\/wp-content\/uploads\/2019\/11\/imh-logo-all-colors-big.jpg","contentUrl":"https:\/\/www.inmotionhosting.com\/blog\/wp-content\/uploads\/2019\/11\/imh-logo-all-colors-big.jpg","width":1630,"height":430,"caption":"InMotion Hosting"},"image":{"@id":"https:\/\/www.inmotionhosting.com\/blog\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/inmotionhosting","https:\/\/x.com\/inmotionhosting"]},{"@type":"Person","@id":"https:\/\/www.inmotionhosting.com\/blog\/#\/schema\/person\/b459c4b748083c4f8431d5312e795796","name":"Sam Page","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/35c230f33cd7aacf52f0f53bc02230a2ee7840b5b221af549d491ab98f65a363?s=96&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/35c230f33cd7aacf52f0f53bc02230a2ee7840b5b221af549d491ab98f65a363?s=96&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/35c230f33cd7aacf52f0f53bc02230a2ee7840b5b221af549d491ab98f65a363?s=96&r=g","caption":"Sam Page"},"url":"https:\/\/www.inmotionhosting.com\/blog\/author\/samp\/"}]}},"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"primary_category":{"id":355,"name":"Dedicated Server Articles","slug":"dedicated-server-hosting","link":"https:\/\/www.inmotionhosting.com\/blog\/dedicated-server-hosting\/"},"_links":{"self":[{"href":"https:\/\/www.inmotionhosting.com\/blog\/wp-json\/wp\/v2\/posts\/82504","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.inmotionhosting.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.inmotionhosting.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.inmotionhosting.com\/blog\/wp-json\/wp\/v2\/users\/116"}],"replies":[{"embeddable":true,"href":"https:\/\/www.inmotionhosting.com\/blog\/wp-json\/wp\/v2\/comments?post=82504"}],"version-history":[{"count":2,"href":"https:\/\/www.inmotionhosting.com\/blog\/wp-json\/wp\/v2\/posts\/82504\/revisions"}],"predecessor-version":[{"id":82507,"href":"https:\/\/www.inmotionhosting.com\/blog\/wp-json\/wp\/v2\/posts\/82504\/revisions\/82507"}],"wp:attachment":[{"href":"https:\/\/www.inmotionhosting.com\/blog\/wp-json\/wp\/v2\/media?parent=82504"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.inmotionhosting.com\/blog\/wp-json\/wp\/v2\/categories?post=82504"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.inmotionhosting.com\/blog\/wp-json\/wp\/v2\/tags?post=82504"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}