As a contrary opinion, I think firewalls are great. I deal with computer security on a regular basis. Do you know how many threats there are? OMG its crazy. Every day I hears of crap that just blows my mind. Just recently OpenSSH_8.9p1 fixed an issue where an external agent can get root access to a system because some code was exposed in sshd that allowed it to respond a a signal. Somehow the "ifdef/endif" were removed. I'm suspicious, to be honest.
There is no service, none, that I would trust. Every single security point has a hole. The best you can do is the "Swiss cheese model." https://en.wikipedia.org/wiki/Swiss_cheese_model If you assume that every security entry point has holes, then a firewall is your first layer of cheese. You can never be 100% sure that you are secure. NEVER. At any point in time, a hither-to unknown/unbelievable exploit will be announced and you have to scramble to patch it. > I mostly don't like firewalls, seems to me it is better to only listen > on the ports one wants to listen on and only listen on those for > specific good reasons. Firewalls are mostly used as a substitute for > such discipline. Also, iptables rules are a pain to set up, looking more > prone to error than not. > > Until I discovered "ufw" front end: it is actually simple to use! > (Imagine, a single, simple command to allow a specific inbound port > number through! What *will* they think of next?) So I used ufw to set up > some firewalls: but belt-and-suspenders, the firewall as an extra layer > of protection NOT the only layer of protection. > > Which means I now get firewall reports in daily logwatch e-mails. > > > Anyway, finally to the point. > > What is going on in this short excerpt (out of a very long e-mail of > such stuff): > >> From 103.203.58.1 - 1 packet to tcp(8001) >> From 103.224.217.31 - 1 packet to tcp(23) >> From 103.229.127.36 - 1 packet to udp(1434) >> From 103.237.146.15 - 1 packet to udp(1900) >> From 103.252.89.123 - 12 packets to >> tcp(2995,15066,15825,17990,22787,50236,51764,52432,55508,61617) >> From 104.40.57.205 - 2 packets to tcp(110,2049) >> From 104.40.57.225 - 1 packet to tcp(26) >> From 104.40.74.178 - 1 packet to tcp(8888) > > Most of it makes sense: > > 8001: They are looking for a web server on a funny port. > 23: THe normal telnet port. > 1434: Something MS SQL. > 1900: Some UPnP thing. > 110, 2049: pop3, NFS. > 8888: Probably hoping for a web server again. > 26: SMTP on a funny port or some file transfer thing or an old firewall > (!) or "Dungeon Siege II" game or "W32.Netsky" malware. > > But what about that those 12-packets 103.252.89.123 sent to 10 different > high ports? (note 12 â 10) > > Are they really expecting services to be running up there? Are they > trying to hit return port numbers through a broken NAT? Is that some > default port-knocking patternâ¦? They are looking for 10-specific things > but their script forget that they had already hit two of them? Or two of > them are two different specific things and hitting those two ports for > each case was just easier? > > > Thanks, > > -kb > > > P.S. I do admit that a firewall makes more sense on my daily laptop than > it does on my servers, because I run a greater variety software on my > laptop. One day I scanned myself and I discovered it was listening on an > unexpected port. Turns out I had Rhythmbox was running at the time, and > it was helpfully defaulting to offering "DAAP Music Sharing". Probably > not a big problem, but still something I don't want and I turned it off. > A firewall prevents such accidental things from being accessible. But a > firewall should not be a primary line of defense, dammit! And I should > still occasionally scan local host, *and* turn off my firewall and scan > my IP address(es) from a different machine⦠> > P.P.S. My decades long dislike of firewalls is *finally* getting trendy > with the impressive name "Zero Trust Architecture", it even has a TLA: > "ZTA". Nice when the world finally catches up here and there. > > _______________________________________________ > Discuss mailing list > Discuss@driftwood.blu.org > https://driftwood.blu.org/mailman/listinfo/discuss > _______________________________________________ Discuss mailing list Discuss@driftwood.blu.org https://driftwood.blu.org/mailman/listinfo/discuss
