Resolve Markdown ordered lists not conforming to styleguidedocs/fix-ordered-list-item-prefix

2 files changed, 11 insertions, 11 deletions

diff --git a/doc/security/rack_attack.md b/doc/security/rack_attack.md
index 3efb19c1526..07e7b3da13b 100644
--- a/doc/security/rack_attack.md
+++ b/doc/security/rack_attack.md
@@ -10,7 +10,7 @@ Rack Attack offers IP whitelisting, blacklisting, Fail2ban style filtering and
 tracking.
 
 **Note:** Starting with 11.2, Rack Attack is disabled by default. To continue
-using this feature, please enable it in your `gitlab.rb` by setting 
+using this feature, please enable it in your `gitlab.rb` by setting
 `gitlab_rails['rack_attack_git_basic_auth'] = true`.
 
 By default, user sign-in, user sign-up (if enabled), and user password reset is
@@ -41,7 +41,7 @@ For more information on how to use these options check out
     }
     ```
 
-3. Reconfigure GitLab:
+1. Reconfigure GitLab:
 
     ```
     sudo gitlab-ctl reconfigure
@@ -98,26 +98,26 @@ In case you want to remove a blocked IP, follow these steps:
     grep "Rack_Attack" /var/log/gitlab/gitlab-rails/production.log
     ```
 
-2. Since the blacklist is stored in Redis, you need to open up `redis-cli`:
+1. Since the blacklist is stored in Redis, you need to open up `redis-cli`:
 
     ```sh
     /opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket
     ```
 
-3. You can remove the block using the following syntax, replacing `<ip>` with
+1. You can remove the block using the following syntax, replacing `<ip>` with
    the actual IP that is blacklisted:
 
     ```
     del cache:gitlab:rack::attack:allow2ban:ban:<ip>
     ```
 
-4. Confirm that the key with the IP no longer shows up:
+1. Confirm that the key with the IP no longer shows up:
 
     ```
     keys *rack::attack*
     ```
 
-5. Optionally, add the IP to the whitelist to prevent it from being blacklisted
+1. Optionally, add the IP to the whitelist to prevent it from being blacklisted
    again (see [settings](#settings)).
 
 ## Troubleshooting
@@ -129,11 +129,11 @@ the load balancer. In that case, you will need to:
 
 1. [Configure `nginx[real_ip_trusted_addresses]`](https://docs.gitlab.com/omnibus/settings/nginx.html#configuring-gitlab-trusted_proxies-and-the-nginx-real_ip-module).
    This will keep users' IPs from being listed as the load balancer IPs.
-2. Whitelist the load balancer's IP address(es) in the Rack Attack [settings](#settings).
-3. Reconfigure GitLab:
+1. Whitelist the load balancer's IP address(es) in the Rack Attack [settings](#settings).
+1. Reconfigure GitLab:
 
     ```
     sudo gitlab-ctl reconfigure
     ```
 
-4. [Remove the block via Redis.](#remove-blocked-ips-from-rack-attack-via-redis)
+1. [Remove the block via Redis.](#remove-blocked-ips-from-rack-attack-via-redis)
diff --git a/doc/security/two_factor_authentication.md b/doc/security/two_factor_authentication.md
index cd290a80314..b770f2544d2 100644
--- a/doc/security/two_factor_authentication.md
+++ b/doc/security/two_factor_authentication.md
@@ -13,8 +13,8 @@ You can read more about it here:
 Users on GitLab, can enable it without any admin's intervention. If you want to
 enforce everyone to set up 2FA, you can choose from two different ways:
 
- 1. Enforce on next login
- 2. Suggest on next login, but allow a grace period before enforcing.
+- Enforce on next login.
+- Suggest on next login, but allow a grace period before enforcing.
 
 In the Admin area under **Settings** (`/admin/application_settings`), look for
 the "Sign-in Restrictions" area, where you can configure both.