{"id":7108,"date":"2017-10-25T11:42:12","date_gmt":"2017-10-25T03:42:12","guid":{"rendered":"http:\/\/rmohan.com\/?p=7108"},"modified":"2017-10-25T11:42:12","modified_gmt":"2017-10-25T03:42:12","slug":"ddos-protection-with-iptables","status":"publish","type":"post","link":"https:\/\/mohan.sg\/?p=7108","title":{"rendered":"DDoS Protection With IPtables"},"content":{"rendered":"

DDoS Protection With IPtables<\/strong><\/p>\n

There are different ways of building your own anti-DDoS rules for iptables. We will be discussing the most effective iptables DDoS protection methods in this comprehensive tutorial.
\nThis guide will teach you how to:
\nSelect the best iptables table and chain to stop DDoS attacks
\nTweak your kernel settings to mitigate the effects of DDoS attacks
\nUse iptables to block most TCP-based DDoS attacks
\nUse iptables SYNPROXY to block SYN floods
\nPlease note that this article is written for professionals who deal with Linux servers on a daily basis.
\nIf you just want to protect your online application from DDoS attacks, you can use our remote protection, a VPS with DDoS protection or a DDoS protected bare metal server.
\nWhile one can do a lot with iptables to block DDoS attacks, there isn\u2019t a way around actual hardware firewalls (we recently reviewed RioRey DDoS mitigation hardware) to detect and stop large DDoS floods.
\nHowever, it isn\u2019t impossible to filter most bad traffic at line rate using iptables!
\nWe\u2019ll only cover protection from TCP-based attacks. Most UDP-based attacks are amplified reflection attacks that will exhaust the network interface card of any common server.
\nThe only mitigation approach that makes sense against these types of attacks is to block them at the edge or core network or even at the carrier already.
\nDid you know we now offer VPS with unmetered bandwidth and DDoS protection in Chicago, Illinois and Bucharest, Romania?
\nIf they are able to reach your server, there isn\u2019t much you can do against those multi-Gbit\/s attacks except to move to a DDoS protected network.
\nanti-DDoS iptables
\nWhat Is IPtables?
\nnetfilter iptables (soon to be replaced by nftables) is a user-space command line utility to configure kernel packet filtering rules developed by netfilter.
\nIt\u2019s the default firewall management utility on Linux systems \u2013 everyone working with Linux systems should be familiar with it or have at least heard of it.
\niptables can be used to filter certain packets, block source or destination ports and IP addresses, forward packets via NAT and a lot of other things.
\nMost commonly it\u2019s used to block destination ports and source IP addresses.
\nWhy Your IPtables Anti-DDoS Rules Suck
\nTo understand why your current iptables rules to prevent DDoS attacks suck, we first have to dig into how iptables works.
\niptables is a command line tool used to set up and control the tables of IP packet filter rules. There are different tables for different purposes.
\nIPtables Tables
\nFilter: The filter table is the default and most commonly used table that rules go to if you don\u2019t use the -t (\u2013table) option.
\nNat: This table is used for Network Address Translation (NAT). If a packet creates a new connection, the nat table gets checked for rules.
\nMangle: The mangle table is used to modify or mark packets and their header information.
\nRaw: This table\u2019s purpose is mainly to exclude certain packets from connection tracking using the NOTRACK target.
\nAs you can see there are four different tables on an average Linux system that doesn\u2019t have non-standard kernel modules loaded. Each of these tables supports a different set of iptables chains.
\nIPtables Chains
\nPREROUTING: raw, nat, mangle
\nApplies to packets that enter the network interface card (NIC)
\nINPUT: filter, mangle
\nApplies to packets destined to a local socket
\nFORWARD: filter, mangle
\nApplies to packets that are being routed through the server
\nOUTPUT: raw, filter, nat, mangle
\nApplies to packets that the server sends (locally generated)
\nPOSTROUTING: nat, mangle
\nApplies to packets that leave the server
\nDepending on what kind of packets you want to block or modify, you select a certain iptables table and a chain that the selected table supports.
\nOf course, we\u2019re still missing an explanation of iptables targets (ACCEPT, DROP, REJECT, etc.), but we\u2019re assuming that if you\u2019re reading this article, you already know how to deal with iptables.
\nWe\u2019re going to explain why your iptables rules suck to stop DDoS and not teach you how to use iptables. Let\u2019s get back to that.
\nIf you want to block a DDoS attack with iptables, performance of the iptables rules is extremely important. Most TCP-based DDoS attack types use a high packet rate, meaning the sheer number of packets per second is what causes the server to go down.
\nThat\u2019s why you want to make sure that you can process and block as many packets per second as possible.
\nYou\u2019ll find that most if not all guides on how to block DDoS attacks using iptables use the filter table and the INPUT chain for anti-DDoS rules.
\nThe issue with this approach is that the INPUT chain is only processed after the PREROUTING and FORWARD chains and therefore only applies if the packet doesn\u2019t match any of these two chains.
\nThis causes a delay in the filtering of the packet which consumes resources. In conclusion, to make our rules as effective as possible, we need to move our anti-DDoS rules as far up the chains as possible.
\nThe first chain that can apply to a packet is the PREROUTING chain, so ideally we\u2019ll want to filter the bad packets in this chain already.
\nHowever, the filter table doesn\u2019t support the PREROUTING chain. To get around this problem, we can simply use the mangle table instead of the filter table for our anti-DDoS iptables rules.
\nIt supports most if not all rules that the filter table supports while also supporting all iptables chains.
\nSo you want to know why your iptables DDoS protection rules suck? It\u2019s because you use the filter table and the INPUT chain to block the bad packets!
\nThe best solution to dramatically increase the performance of your iptables rules and therefore the amount of (TCP) DDoS attack traffic they can filter is to use the mangle table and the PREROUTING chain!
\nThe Best Linux Kernel Settings to Mitigate DDoS
\nAnother common mistake is that people don\u2019t use optimized kernel settings to better mitigate the effects of DDoS attacks.
\nNote that this guide focuses on CentOS 7 as the operating system of choice. CentOS 7 includes a recent version of iptables and support of the new SYNPROXY target.
\nWe won\u2019t cover every single kernel setting that you need to adjust in order to better mitigate DDoS with iptables.
\nInstead, we provide a set of CentOS 7 kernel settings that we would use. Just put the below in your \/etc\/sysctl.conf file and apply the settings with sysctl -p.
\nAnti-DDoS Kernel Settings (sysctl.conf)
\nkernel.printk = 4 4 1 7
\nkernel.panic = 10
\nkernel.sysrq = 0
\nkernel.shmmax = 4294967296
\nkernel.shmall = 4194304
\nkernel.core_uses_pid = 1
\nkernel.msgmnb = 65536
\nkernel.msgmax = 65536
\nvm.swappiness = 20
\nvm.dirty_ratio = 80
\nvm.dirty_background_ratio = 5
\nfs.file-max = 2097152
\nnet.core.netdev_max_backlog = 262144
\nnet.core.rmem_default = 31457280
\nnet.core.rmem_max = 67108864
\nnet.core.wmem_default = 31457280
\nnet.core.wmem_max = 67108864
\nnet.core.somaxconn = 65535
\nnet.core.optmem_max = 25165824
\nnet.ipv4.neigh.default.gc_thresh1 = 4096
\nnet.ipv4.neigh.default.gc_thresh2 = 8192
\nnet.ipv4.neigh.default.gc_thresh3 = 16384
\nnet.ipv4.neigh.default.gc_interval = 5
\nnet.ipv4.neigh.default.gc_stale_time = 120
\nnet.netfilter.nf_conntrack_max = 10000000
\nnet.netfilter.nf_conntrack_tcp_loose = 0
\nnet.netfilter.nf_conntrack_tcp_timeout_established = 1800
\nnet.netfilter.nf_conntrack_tcp_timeout_close = 10
\nnet.netfilter.nf_conntrack_tcp_timeout_close_wait = 10
\nnet.netfilter.nf_conntrack_tcp_timeout_fin_wait = 20
\nnet.netfilter.nf_conntrack_tcp_timeout_last_ack = 20
\nnet.netfilter.nf_conntrack_tcp_timeout_syn_recv = 20
\nnet.netfilter.nf_conntrack_tcp_timeout_syn_sent = 20
\nnet.netfilter.nf_conntrack_tcp_timeout_time_wait = 10
\nnet.ipv4.tcp_slow_start_after_idle = 0
\nnet.ipv4.ip_local_port_range = 1024 65000
\nnet.ipv4.ip_no_pmtu_disc = 1
\nnet.ipv4.route.flush = 1
\nnet.ipv4.route.max_size = 8048576
\nnet.ipv4.icmp_echo_ignore_broadcasts = 1
\nnet.ipv4.icmp_ignore_bogus_error_responses = 1
\nnet.ipv4.tcp_congestion_control = htcp
\nnet.ipv4.tcp_mem = 65536 131072 262144
\nnet.ipv4.udp_mem = 65536 131072 262144
\nnet.ipv4.tcp_rmem = 4096 87380 33554432
\nnet.ipv4.udp_rmem_min = 16384
\nnet.ipv4.tcp_wmem = 4096 87380 33554432
\nnet.ipv4.udp_wmem_min = 16384
\nnet.ipv4.tcp_max_tw_buckets = 1440000
\nnet.ipv4.tcp_tw_recycle = 0
\nnet.ipv4.tcp_tw_reuse = 1
\nnet.ipv4.tcp_max_orphans = 400000
\nnet.ipv4.tcp_window_scaling = 1
\nnet.ipv4.tcp_rfc1337 = 1
\nnet.ipv4.tcp_syncookies = 1
\nnet.ipv4.tcp_synack_retries = 1
\nnet.ipv4.tcp_syn_retries = 2
\nnet.ipv4.tcp_max_syn_backlog = 16384
\nnet.ipv4.tcp_timestamps = 1
\nnet.ipv4.tcp_sack = 1
\nnet.ipv4.tcp_fack = 1
\nnet.ipv4.tcp_ecn = 2
\nnet.ipv4.tcp_fin_timeout = 10
\nnet.ipv4.tcp_keepalive_time = 600
\nnet.ipv4.tcp_keepalive_intvl = 60
\nnet.ipv4.tcp_keepalive_probes = 10
\nnet.ipv4.tcp_no_metrics_save = 1
\nnet.ipv4.ip_forward = 0
\nnet.ipv4.conf.all.accept_redirects = 0
\nnet.ipv4.conf.all.send_redirects = 0
\nnet.ipv4.conf.all.accept_source_route = 0
\nnet.ipv4.conf.all.rp_filter = 1
\nThese sysctl.conf settings help to maximize the performance of your server under DDoS as well as the effectiveness of the iptables rules that we\u2019re going to provide in this guide.
\nThe Actual IPtables Anti-DDoS Rules
\nConsidering you now know that you need to use the mangle table and the PREROUTING chain as well as optimized kernel settings to mitigate the effects of DDoS attacks, we\u2019ll now move on to a couple of example rules to mitigate most TCP DDoS attacks.
\nDDoS attacks are complex.
\nThere are many different types of DDoS and it\u2019s close to impossible to maintain signature-based rules against all of them.
\nBut luckily there is something called connection tracking (nf_conntrack kernel module), which can help us to mitigate almost any TCP-based DDoS attack that doesn\u2019t use SYN packets that seem legitimate.
\nThis includes all types of ACK and SYN-ACK DDoS attacks as well as DDoS attacks that use bogus TCP flags.
\nWe\u2019ll start with just five simple iptables rules that will already drop many TCP-based DDoS attacks.
\nBlock Invalid Packets
\niptables -t mangle -A PREROUTING -m conntrack –ctstate INVALID -j DROP
\nThis rule blocks all packets that are not a SYN packet and don\u2019t belong to an established TCP connection.
\nBlock New Packets That Are Not SYN
\niptables -t mangle -A PREROUTING -p tcp ! –syn -m conntrack –ctstate NEW -j DROP
\nThis blocks all packets that are new (don\u2019t belong to an established connection) and don\u2019t use the SYN flag. This rule is similar to the \u201cBlock Invalid Packets\u201d one, but we found that it catches some packets that the other one doesn\u2019t.
\nBlock Uncommon MSS Values
\niptables -t mangle -A PREROUTING -p tcp -m conntrack –ctstate NEW -m tcpmss ! –mss 536:65535 -j DROP
\nThe above iptables rule blocks new packets (only SYN packets can be new packets as per the two previous rules) that use a TCP MSS value that is not common. This helps to block dumb SYN floods.
\nBlock Packets With Bogus TCP Flags
\niptables -t mangle -A PREROUTING -p tcp –tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
\niptables -t mangle -A PREROUTING -p tcp –tcp-flags FIN,SYN FIN,SYN -j DROP
\niptables -t mangle -A PREROUTING -p tcp –tcp-flags SYN,RST SYN,RST -j DROP
\niptables -t mangle -A PREROUTING -p tcp –tcp-flags FIN,RST FIN,RST -j DROP
\niptables -t mangle -A PREROUTING -p tcp –tcp-flags FIN,ACK FIN -j DROP
\niptables -t mangle -A PREROUTING -p tcp –tcp-flags ACK,URG URG -j DROP
\niptables -t mangle -A PREROUTING -p tcp –tcp-flags ACK,FIN FIN -j DROP
\niptables -t mangle -A PREROUTING -p tcp –tcp-flags ACK,PSH PSH -j DROP
\niptables -t mangle -A PREROUTING -p tcp –tcp-flags ALL ALL -j DROP
\niptables -t mangle -A PREROUTING -p tcp –tcp-flags ALL NONE -j DROP
\niptables -t mangle -A PREROUTING -p tcp –tcp-flags ALL FIN,PSH,URG -j DROP
\niptables -t mangle -A PREROUTING -p tcp –tcp-flags ALL SYN,FIN,PSH,URG -j DROP
\niptables -t mangle -A PREROUTING -p tcp –tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
\nThe above ruleset blocks packets that use bogus TCP flags, ie. TCP flags that legitimate packets wouldn\u2019t use.
\nBlock Packets From Private Subnets (Spoofing)
\niptables -t mangle -A PREROUTING -s 224.0.0.0\/3 -j DROP
\niptables -t mangle -A PREROUTING -s 169.254.0.0\/16 -j DROP
\niptables -t mangle -A PREROUTING -s 172.16.0.0\/12 -j DROP
\niptables -t mangle -A PREROUTING -s 192.0.2.0\/24 -j DROP
\niptables -t mangle -A PREROUTING -s 192.168.0.0\/16 -j DROP
\niptables -t mangle -A PREROUTING -s 10.0.0.0\/8 -j DROP
\niptables -t mangle -A PREROUTING -s 0.0.0.0\/8 -j DROP
\niptables -t mangle -A PREROUTING -s 240.0.0.0\/5 -j DROP
\niptables -t mangle -A PREROUTING -s 127.0.0.0\/8 ! -i lo -j DROP
\nThese rules block spoofed packets originating from private (local) subnets. On your public network interface you usually don\u2019t want to receive packets from private source IPs.
\nThese rules assume that your loopback interface uses the 127.0.0.0\/8 IP space.
\nThese five sets of rules alone already block many TCP-based DDoS attacks at very high packet rates.
\nWith the kernel settings and rules mentioned above, you\u2019ll be able to filter ACK and SYN-ACK attacks at line rate.
\nAdditional Rules
\niptables -t mangle -A PREROUTING -p icmp -j DROP
\nThis drops all ICMP packets. ICMP is only used to ping a host to find out if it\u2019s still alive. Because it\u2019s usually not needed and only represents another vulnerability that attackers can exploit, we block all ICMP packets to mitigate Ping of Death (ping flood), ICMP flood and ICMP fragmentation flood.
\niptables -A INPUT -p tcp -m connlimit –connlimit-above 80 -j REJECT –reject-with tcp-reset
\nThis iptables rule helps against connection attacks. It rejects connections from hosts that have more than 80 established connections. If you face any issues you should raise the limit as this could cause troubles with legitimate clients that establish a large number of TCP connections.
\niptables -A INPUT -p tcp -m conntrack –ctstate NEW -m limit –limit 60\/s –limit-burst 20 -j ACCEPT
\niptables -A INPUT -p tcp -m conntrack –ctstate NEW -j DROP
\nLimits the new TCP connections that a client can establish per second. This can be useful against connection attacks, but not so much against SYN floods because the usually use an endless amount of different spoofed source IPs.
\niptables -t mangle -A PREROUTING -f -j DROP
\nThis rule blocks fragmented packets. Normally you don\u2019t need those and blocking fragments will mitigate UDP fragmentation flood. But most of the time UDP fragmentation floods use a high amount of bandwidth that is likely to exhaust the capacity of your network card, which makes this rule optional and probably not the most useful one.
\niptables -A INPUT -p tcp –tcp-flags RST RST -m limit –limit 2\/s –limit-burst 2 -j ACCEPT
\niptables -A INPUT -p tcp –tcp-flags RST RST -j DROP
\nThis limits incoming TCP RST packets to mitigate TCP RST floods. Effectiveness of this rule is questionable.
\nMitigating SYN Floods With SYNPROXY
\nSYNPROXY is a new target of iptables that has been added in Linux kernel version 3.12 and iptables 1.4.21. CentOS 7 backported the feature and it\u2019s available in its 3.10 default kernel.
\nThe purpose of SYNPROXY is to check whether the host that sent the SYN packet actually establishes a full TCP connection or just does nothing after it sent the SYN packet.
\nIf it does nothing, it discards the packet with minimal performance impact.
\nWhile the iptables rules that we provided above already block most TCP-based attacks, the attack type that can still slip through them if sophisticated enough is a SYN flood.
\nIt\u2019s important to note that the performance of the rules will always be better if we find a certain pattern or signature to block, such as packet length (-m length), TOS (-m tos), TTL (-m ttl) or strings and hex values (-m string and -m u32 for the more advanced users).
\nBut in some rare cases that\u2019s not possible or at least not easy to achieve. So, in these cases, you can make use of SYNPROXY.
\nHere are iptables SYNPROXY rules that help mitigate SYN floods that bypass our other rules:<\/p>\n

hese rules apply to all ports. If you want to use SYNPROXY only on certain TCP ports that are active (recommended \u2013 also you should block all TCP ports that are not in use using the mangle table and PREROUTING chain), you can just add \u2013dport 80 to each of the rules if you want to use SYNPROXY on port 80 only.
\nTo verify that SYNPROXY is working, you can do watch -n1 cat \/proc\/net\/stat\/synproxy. If the values change when you establish a new TCP connection to the port you use SYNPROXY on, it works.
\nThe Complete IPtables Anti-DDoS Rules
\nIf you don\u2019t want to copy & paste each single rule we discussed in this article, you can use the below ruleset for basic DDoS protection of your Linux server.
\n### 1: Drop invalid packets ###
\n\/sbin\/iptables -t mangle -A PREROUTING -m conntrack –ctstate INVALID -j DROP <\/p>\n

### 2: Drop TCP packets that are new and are not SYN ###
\n\/sbin\/iptables -t mangle -A PREROUTING -p tcp ! –syn -m conntrack –ctstate NEW -j DROP <\/p>\n

### 3: Drop SYN packets with suspicious MSS value ###
\n\/sbin\/iptables -t mangle -A PREROUTING -p tcp -m conntrack –ctstate NEW -m tcpmss ! –mss 536:65535 -j DROP <\/p>\n

### 4: Block packets with bogus TCP flags ###
\n\/sbin\/iptables -t mangle -A PREROUTING -p tcp –tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
\n\/sbin\/iptables -t mangle -A PREROUTING -p tcp –tcp-flags FIN,SYN FIN,SYN -j DROP
\n\/sbin\/iptables -t mangle -A PREROUTING -p tcp –tcp-flags SYN,RST SYN,RST -j DROP
\n\/sbin\/iptables -t mangle -A PREROUTING -p tcp –tcp-flags FIN,RST FIN,RST -j DROP
\n\/sbin\/iptables -t mangle -A PREROUTING -p tcp –tcp-flags FIN,ACK FIN -j DROP
\n\/sbin\/iptables -t mangle -A PREROUTING -p tcp –tcp-flags ACK,URG URG -j DROP
\n\/sbin\/iptables -t mangle -A PREROUTING -p tcp –tcp-flags ACK,FIN FIN -j DROP
\n\/sbin\/iptables -t mangle -A PREROUTING -p tcp –tcp-flags ACK,PSH PSH -j DROP
\n\/sbin\/iptables -t mangle -A PREROUTING -p tcp –tcp-flags ALL ALL -j DROP
\n\/sbin\/iptables -t mangle -A PREROUTING -p tcp –tcp-flags ALL NONE -j DROP
\n\/sbin\/iptables -t mangle -A PREROUTING -p tcp –tcp-flags ALL FIN,PSH,URG -j DROP
\n\/sbin\/iptables -t mangle -A PREROUTING -p tcp –tcp-flags ALL SYN,FIN,PSH,URG -j DROP
\n\/sbin\/iptables -t mangle -A PREROUTING -p tcp –tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP <\/p>\n

### 5: Block spoofed packets ###
\n\/sbin\/iptables -t mangle -A PREROUTING -s 224.0.0.0\/3 -j DROP
\n\/sbin\/iptables -t mangle -A PREROUTING -s 169.254.0.0\/16 -j DROP
\n\/sbin\/iptables -t mangle -A PREROUTING -s 172.16.0.0\/12 -j DROP
\n\/sbin\/iptables -t mangle -A PREROUTING -s 192.0.2.0\/24 -j DROP
\n\/sbin\/iptables -t mangle -A PREROUTING -s 192.168.0.0\/16 -j DROP
\n\/sbin\/iptables -t mangle -A PREROUTING -s 10.0.0.0\/8 -j DROP
\n\/sbin\/iptables -t mangle -A PREROUTING -s 0.0.0.0\/8 -j DROP
\n\/sbin\/iptables -t mangle -A PREROUTING -s 240.0.0.0\/5 -j DROP
\n\/sbin\/iptables -t mangle -A PREROUTING -s 127.0.0.0\/8 ! -i lo -j DROP <\/p>\n

### 6: Drop ICMP (you usually don’t need this protocol) ###
\n\/sbin\/iptables -t mangle -A PREROUTING -p icmp -j DROP <\/p>\n

### 7: Drop fragments in all chains ###
\n\/sbin\/iptables -t mangle -A PREROUTING -f -j DROP <\/p>\n

### 8: Limit connections per source IP ###
\n\/sbin\/iptables -A INPUT -p tcp -m connlimit –connlimit-above 111 -j REJECT –reject-with tcp-reset <\/p>\n

### 9: Limit RST packets ###
\n\/sbin\/iptables -A INPUT -p tcp –tcp-flags RST RST -m limit –limit 2\/s –limit-burst 2 -j ACCEPT
\n\/sbin\/iptables -A INPUT -p tcp –tcp-flags RST RST -j DROP <\/p>\n

### 10: Limit new TCP connections per second per source IP ###
\n\/sbin\/iptables -A INPUT -p tcp -m conntrack –ctstate NEW -m limit –limit 60\/s –limit-burst 20 -j ACCEPT
\n\/sbin\/iptables -A INPUT -p tcp -m conntrack –ctstate NEW -j DROP <\/p>\n

### 11: Use SYNPROXY on all ports (disables connection limiting rule) ###
\n# Hidden – unlock content above in “Mitigating SYN Floods With SYNPROXY” section
\nBonus Rules
\nHere are some more iptables rules that are useful to increase the overall security of a Linux server:
\n### SSH brute-force protection ###
\n\/sbin\/iptables -A INPUT -p tcp –dport ssh -m conntrack –ctstate NEW -m recent –set
\n\/sbin\/iptables -A INPUT -p tcp –dport ssh -m conntrack –ctstate NEW -m recent –update –seconds 60 –hitcount 10 -j DROP <\/p>\n

### Protection against port scanning ###
\n\/sbin\/iptables -N port-scanning
\n\/sbin\/iptables -A port-scanning -p tcp –tcp-flags SYN,ACK,FIN,RST RST -m limit –limit 1\/s –limit-burst 2 -j RETURN
\n\/sbin\/iptables -A port-scanning -j DROP
\nConclusion
\nThis tutorial demonstrates some of the most powerful and effective methods to stop DDoS attacks using iptables.
\nWe\u2019ve successfully mitigated DDoS attacks that peaked at multiple million packets per second using these iptables rules.
\nEvery single guide on the same topic that we had researched provided inefficient methods to stop DDoS traffic or only a very limited number of iptables rules.
\nIf used correctly, iptables is an extremely powerful tool that\u2019s able to block different types of DDoS attacks at line-rate of 1GigE NICs and close to line-rate of 10GigE NICs.<\/p>\n","protected":false},"excerpt":{"rendered":"

DDoS Protection With IPtables<\/p>\n

There are different ways of building your own anti-DDoS rules for iptables. We will be discussing the most effective iptables DDoS protection methods in this comprehensive tutorial. This guide will teach you how to: Select the best iptables table and chain to stop DDoS attacks Tweak your kernel settings to mitigate […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[17],"tags":[],"_links":{"self":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/7108"}],"collection":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=7108"}],"version-history":[{"count":1,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/7108\/revisions"}],"predecessor-version":[{"id":7109,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/7108\/revisions\/7109"}],"wp:attachment":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=7108"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=7108"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=7108"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}