I am hosting a web server, both standard and SSL. Both work fine currently.

In my logs, I've noticed what seems like a distributed port-scan: 10-15 port queries from random hosts occuring within seconds of eachother every few hours.

I have fail2ban up and running, but since the source IPs are always different, it doesn't catch this kind of attack. The destination port is always different, but the source port is always 443.

Is an effective way to block this attack to block packets with source port 443, or is that going to interfere with my https server?


  • I don't think this traffic is malicious. I've logged the same, on a desktop machine, and what I found was that the source IPs were almost invariably from a well-known CDN (Akamai, Apple). My browsing habits lead me to believe that these are long-standing connections whose state iptables has lost track of; it therefore no longer regards these packets as part of ESTABLISHED or RELATED connections and drops them.
    – chb
    Commented Jul 21, 2020 at 16:51

2 Answers 2


I wouldn't.

Your attacker is already distributing scans across IP, which is much harder to do that distributing across ports. Blocking a port would only send you down a rabbit-hole (what happens if they change to port 80, 21, 1024....etc)

The real downside is that this could create future operational issues for you down the road, you never know when you might need some packets with source port 443.

Probably worthwhile to run a full scan of the box to see what open ports there are on it, before the attacker finds them.


While ports 0-1024 are reserved, their use isn't strictly forbidden by the standards, so it could be legitimate traffic, even if it's quite unusual.

Moreover, blocking that source port won't make an attacker's task harder: changing the source port is trivial, so I would not block it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .