Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month, online, via Jitsi Meet.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Trying to connect to internet in Debian



Thanks everyone for these thoughtful and helpful replies.

I did eventually get the firewall working in Debian, and connected to the 
internet.  It turns out, in fact, that my approach of using another machine 
to run ufw and iptables-save and ip6tables-save actually does generate a 
correct, usable list of iptables settings which I can bring over to my Debian 
machine.  (I don't believe this amounts to using ufw and iptables on the same 
machine in any way that could cause problems.)  The reason why I didn't 
immediately succeed in this approach was that, slightly before I tried it, 
someone else in a different floor of my apartment building turned off some 
fuses for their unit which, due to odd building wiring, also disabled the 
power outlet in the basement that my Verizon ONT was connected to.  
(ONT=Optical Network Terminal, it's the device that directly converts light 
signals running through fiber to electrical signals running through wire.)  
So, even though I had a correct set of iptables settings, putting those 
settings into iptables on my Debian machine still didn't give me internet 
access because my router had become non-functional slightly earlier.  After 
fixing the fuse problem and restarting the router, everything was fine.

Main things I've learned from this discussion:

1. Although firewalls are useful on Linux, the need for a firewall on Linux 
is not as strong as I thought.  I still want to use a firewall on my Linux 
machines (not just the router's network firewall) whenever possible.

2. It is a defensible choice to leave your machine's firewall off at least 
briefly while connecting to the internet, if you do it from behind a router 
that you sufficiently trust, where the router has its own firewall and 
doesn't give your machine a publicly accessible IP address, and you believe 
there are no malicious people or devices that also use the same router.

3. Firewalls don't actually help protect against the security holes that come 
with web browsing, nor against some other attacks coming over your machine's 
internet connection.

4. Firewalls help only against attacks which involve a piece of software 
already on your machine that's listening on some port.

5. On the average Linux machine, there are supposed to be only a small number 
of processes listening on ports for connections you didn't initiate.  In 
principle, you should be able to shut down all these processes while still 
being able to do things like web browsing and manually checking for updates.  
There are Linux tools that aim to tell you which processes currently running 
on your machine are listening to ports, and which ports they're listening to. 
 These tools include ss, nmap and (although it's deprecated) netstat.

6. Fail2ban is a way to help protect against repeated attacks that get past 
your firewall (such as brute-force attacks), though it only works if you get 
multiple repeated attacks coming from the same IP address.

Reasons why I still think a firewall is worthwhile:

7. I don't completely believe that I will find all potential listeners by 
using ss and nmap.  In the future, a process may start running and listening 
to a port even though that process doesn't do it right now.  Also, it's 
conceivable that malware has sneaked its way into a distro, or gotten onto my 
machine in some other way, where the malware doesn't deliver its "payload" 
until it is triggered by receiving a message from outside on some port.  
After reading some of the entries in the Underhanded C Code Contest, I am not 
confident that Linux distros are free of malware.

8. The procedure of running ss or nmap, looking up basic info about the 
processes that come up (which won't tell you the whole truth), and 
selectively shutting down some of these processes doesn't seem optimal. 
Turning on a firewall that's configured like "ufw enable" is a considerably 
simpler way of achieving the same goals.  It doesn't require any trust in the 
processes that are listening to ports.

9. If I use ssh or samba or dhcp and decide it's safe to use them when 
connected to the Verizon router in my apartment, I may not feel as safe when 
using another Wifi network.  Having a firewall on protects me in case of 
potential connection to another Wifi network.  I can set up zones in my 
firewall so that configurations get changed appropriately when I'm on another 
network.

Final note: My main conclusion is that I need better protection against 
attacks that make some use of the user's browser, since a firewall won't help 
with that.  I don't know what the best protection tools are there.

On Sat, Jan 17, 2026, at 4:56 PM, Dan Ritter wrote:
> markw at mohawksoft.com wrote: 
>> 
>> > Of course, if you can recommend a way of finding out which of the
>> > thousands of packages that currently are or might later be on my machine
>> > could be listening to the network, I would appreciate hearing.  That 
>> > would
>> > be useful information.  I just don't know it.
>> 
>> netstat -nap | grep LISTENING
>
>
> Add -l and you don't need to grep for it; all the output will be
> listeners.
>
> -dsr-



Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org