-1

Two days ago I built a Debian 10 server in the United States for use as a file server for my web application. When I created the server, I installed the fail2ban package and configured a basic, minimal firewall using the following rules:

*filter

# Allow all loopback (lo0) traffic and reject traffic
# to localhost that does not originate from lo0.
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -s 127.0.0.0/8 -j REJECT

# Allow ping.
-A INPUT -p icmp -m state --state NEW --icmp-type 8 -j ACCEPT

# Allow SSH connections.
-A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT

# Allow inbound traffic from established connections.
# This includes ICMP error returns.
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Log what was incoming but denied (optional but useful).
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables_INPUT_denied: " --log-level 7

# Reject all other inbound.
-A INPUT -j REJECT

# Log any traffic which was sent to you
# for forwarding (optional but useful).
-A FORWARD -m limit --limit 5/min -j LOG --log-prefix "iptables_FORWARD_denied: " --log-level 7

# Reject all traffic forwarding.
-A FORWARD -j REJECT

COMMIT

Today when I checked my firewall, I found the following:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
f2b-sshd   tcp  --  anywhere             anywhere             multiport dports ssh
ACCEPT     all  --  anywhere             anywhere
REJECT     all  --  127.0.0.0/8          anywhere             reject-with icmp-port-unreachable
ACCEPT     icmp --  anywhere             anywhere             state NEW icmp echo-request
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh state NEW
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
LOG        all  --  anywhere             anywhere             limit: avg 5/min burst 5 LOG level debug prefix "iptables_INPUT_denied: "
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
LOG        all  --  anywhere             anywhere             limit: avg 5/min burst 5 LOG level debug prefix "iptables_FORWARD_denied: "
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain f2b-sshd (1 references)
target     prot opt source               destination
REJECT     all  --  49.88.112.114        anywhere             reject-with icmp-port-unreachable
RETURN     all  --  anywhere             anywhere

There are only two user accounts on the server, the root account and a personal account for myself. I'm not a firewall expert but the Chain f2b-sshd entry looks suspicious to me:

When I run whois on that IP address, I see that it originated somewhere in China.

I have other production servers that have been running for over a year that are built on Debian 9 and I've never seen entries like this ever.

  1. Does this entry indicate that someone at that IP address has tried to break into my server?
  2. If the answer is "yes", is Debian 10 now recording all break-in attempts with entries like this?
  3. Are there additional steps I should take to secure my server?
  • 2
    It is unclear what your fail2ban configuration actually does, which means it is unclear what triggered this block (trying to break in or just scanning) and if fail2ban will really find all break-in attempts (probably not). – Steffen Ullrich Feb 20 at 20:54
  • You don't include your fail2ban configs, so we can't comment on what fail2ban is doing... – schroeder Feb 20 at 21:57
  • 2
    This is very common, and is how fail2ban has worked for quite some time. Sure, it indicates that someone may be trying to log in, unsuccessfully. This doesn't have anything to do with your Debian version. – multithr3at3d Feb 20 at 22:30
  • A common configuration for fail2ban creates iptables rules to exclude network traffic from addresses that seem to be a source of attacks. "f2b-sshd" is the name for the rule chain that does this by default when fail2ban is installed on Ubuntu, perhaps that's true for Debian as well. If you want to know what fail2ban is up to, look at /var/log/fail2ban.log or your local installation's equivalent.If your older system is connected to the Internet but not recording password attempts, this suggests your monitoring is turned off/inactive or a firewall is preventing the attempts. – gbroiles Feb 21 at 18:10
  • Our machines (public IP addresses throughout) had hundreds of login attempts via SSH a minute, originating from all over the world, last I looked (a few years back). We configured filters like fail2ban not to thwart intruders but to avoid the non-trivial workload and keeping log files reasonably clean. If there is even a remote possibility that the attempt to log in to root or another system account with some dictionary password will work, you have much more serious problems right there. – vonbrand Feb 23 at 3:01
0

I have other production servers that have been running for over a year that are built on Debian 9 and I've never seen entries like this ever.

I have difficulty believing that. fail2ban operates by adding "probationary" addresses that hit too many logs in too little time to special chains for a configurable amount of time. "f2b-sshd" is the chain for SSH scanners, which are legion. On a not particularly well known box facing the Internet this instant I'm recording about one thousand attempts per day.

And yes, I even got your same subnet scanning. Actually I have now

TARPIT  tcp  -- 49.88.0.0/16    0.0.0.0/0    -j TARPIT --tarpit

for simplicity's sake.

It is not believable that an exposed box would "see nothing of the kind" after one year. Either your other boxes aren't exposed to default SSH (for example you SSH on port 11111 while having port 22 firewalled off), or fail2ban there is not working properly. Your new box seems okay, but you may want to check the auth log on the others.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.