Tightening Debian / Devuan Update Security

This is just a couple of fairly minor technical notes on things that can be done to reduce the risk of a “Man-in-the-middle” attack on various network traffic, and in particular on updates done to a Devuan, Debian, Ubuntu type of Linux. (Windows and Mac users can bail now ;-)

There’s two things that will be covered. First, the simple one of configuring a system wide proxy server default. The second, setting your /etc/apt/sources.list file to be a bit more paranoid about “sources and methods” ;-)

Do note that things change over time, and especially with SystemD screwing around with things, who knows what it will bugger next. So, when in doubt, check your man pages and test your changes. Heck, even when not in doubt…

Also note that I’m using an Armbian Debian system as the model for the posting. Ubuntu and Devuan will have different repositories / mirrors. Folks using them will use other entries, but I’m sticking with Debian for the posting as 1) I only use plain Debian on systems I don’t care about, so nothing of my config will leak for those systems. 2) More folks are likely to use a plain Debian / Armbian than a Devuan anyway, and Devuan doesn’t have many mirror choices (yet). 3) I don’t really like Ubuntu ;-0

The basic process used here will be data flow encryption. Some decades or three ago folks figured out that devices could “snoop” on internet packets and see what you were doing. Then other folks figured they could encrypt that stuff. Then folks figured out “contact tracing” or “traffic analysis” would still yield useful information by looking at your IP address and the IP address you were talking to. Then the other other folks figured out using proxy servers and tunnels would hide that. Then… So just realize it’s a bit of an ongoing escalating war between snoopers and privacy.

Also realize that some TLAs (Three Letter Agencies from all over the world, though the UK likes four letters, go figure ;-) and various hackers are fond of trying to insert themselves in the middle of your traffic so they can watch each packet go by and maybe change some of them. The “Man in the Middle” or MTM attack. Signing things with encrypted signatures to assure identity soon followed… There are now relatively easy to use protocols to assure that you are talking to the site you think you are talking with, and that bits sent to you arrive unchanged. Are they perfect? Depends on how skilled and subtle you think the TLAs might be… The protocols are generally thought to be secure, but it is a race.

A “proxy server” is your own personal MTM device that hides who you are. I use one at home, called Squid, on a Raspberry Pi Model 2. I’ve not seen any slowdown. There are also more public proxy servers all over the world. Most corporations use / require a proxy server to get to the internet. Why? Because folks in the Big Bad World will try to shove stuff at your computer and the proxy server can know about and stop a lot of it. The site admin can also configure the proxy server to deny outgoing connections to things that are illegal, or inappropriate for work (sorry, no porn for you…)

My personal proxy server adds a little bit of security and privacy, but really, all data flows originate from my one house IP address, so not really helping all that much. I’ve mostly done it to keep practiced. But it does mask a little bit the many and several devices I use to do things on the internet. It also means attacks will tend to hit an irrelevant PiM2 and not even know about my interior lab router and the entirely different IP addresses behind it.

Most folks only configure a Proxy Server in their browser. Used just for browsing. But you can also configure a system wide default. I’m doing this because Chromium on the Armbian / Debian / Devuan / and likely Ubuntu set on my ARM based computers declines to let me set a proxy server and ONLY looks at the system default. (Why? When the commercial Chrome does? All I can say is “Why? Don’t ask why. Down that path lies insanity and ruin.” -E.M.Smith”) It just is. Deal with it.

So here’s a page that talks about a couple of ways to configure system wide proxy services.


It has a couple of suggested ways. I’m going with this one:

For General proxy:

touch /etc/profile.d/proxy.sh
add the following:

export ftp_proxy=ftp://user:password@host:port
export http_proxy=http://user:password@host:port
export https_proxy=https://user:password@host:port
export socks_proxy=https://user:password@host:port

You don’t really need to do the “touch” bit. Just edit proxy.sh and it will come into existence. So “vi /etc/profile.d/proxy.sh” is just as effective. Note that you only need the “user:password” part if your proxy server requires a login. Mine does not. Here’s a sample of what mine looks like:

root@OdroidN2:/etc/apt# cat ../profile.d/proxy.sh 
#export ftp_proxy=ftp://user:password@host:port
export ftp_proxy=
export http_proxy=

I used the IP Number so that no DNS activity is required for it to work. Oh,and I’ve changed the actual IP number for this posting to be an ‘example’. It is generally a good idea to not put your real IPs in postings or comments ;-)

Note that I left in the first example line, with # at the front to make it a comment, so that there’s documentation in the file of how to do the user:password@ bit.

So now, at least in theory, my Chromium will also use the Squid Proxy server. (I’ll test it later).

You can also send your ‘apt’ system update requests through a proxy server, along with some other data types, but I’ve not done that. (There’s a limit to my security concerns, honest there is 8-)

For APT proxy:

touch /etc/apt/apt.conf.d/99HttpProxy
add the following:

Acquire::http::Proxy “http://user:password@host:port”;
For wget:

nano /etc/wgetrc
find and uncomment proxy lines or add them if not present

http_proxy = http://user:password@host:port
https_proxy = …

I generally like to have my own local repository for systems, so most of my traffic / updates goes against it. Mostly it is only “disposable” systems where I let it run to the internet first. New installs. Things used for watching videos. That kind of stuff. So going all full secure is a bit silly on them. When I really care, I make my own repository copy and point my systems at it. That has it’s own level of authentication / security and will not be covered here. For a box / board used to watch TV, I’m happy to have my apt-update go straight out the Telco Router. Do I really care they might know I’ve got a Debian or Devuan system and I’m keeping it current?

But I do want to prevent them from changing packets as they come to me.

apt-get encryption

Should you need more information about how to configure apt, see:

There’s a simple thing you can do to make your apt-get update and apt-get upgrade more secure. Encrypt your connection to the server. It slows the process down a very small amount. Not really noticed on an Odroid N2, but it might be an issue on a Pi Zero. Try it and see.

To do the encryption, you add one letter to your apt/sources.list entry. “s”.

root@OdroidN2:/etc/apt# cat sources.list.save
deb http://httpredir.debian.org/debian buster main contrib non-free
#deb-src http://httpredir.debian.org/debian buster main contrib non-free

Here you can see that the saved version of my /etc/apt/sources.list file has me doing an “http” type file transfer. Change that to “https” and it does an encrypted transfer. Folks can still tell you are talking to the server, but they can’t see the packet contents in flight and if they try to change it, the transfer fails. Also note I’m using “deb” so getting binary packages. I could change that to “deb-src” and get source packages, then compile them myself. I’m willing to accept that the binaries being sent to me are correct (though I have a choice to not trust that…)

Finally, note the “httpredir” site. That’s the mirror redirector. It will choose what it thinks is the best mirror site for you at any one time. This is both a blessing and a curse. You need not think about it, and your traffic may tend to go to different destinations at different times, so buggering a given name / IP for a MTM gets harder. OTOH, you have no idea what site you will get your OS parts from nor who is running it… You might be getting your OS updates from Bulgaria. NSA could plop down a Big Fast Mirror and then traffic would gravitate to it.

So I changed to a particular site. Not due to being particularly worried that the NSA might want to watch the same movies I do, but mostly just to play with it. The list of mirrors for Debian is here:


So, say you are in Australia and you don’t want your update requests to leave the island (you know, covid and quarantine and all that ;-) You could use:


Note this is an ftp site, not an https site. But your bits never go to China nor travel over USA wires…

Or you can go further down the page to the secondary server lists and use:

mirror.aarnet.edu.au /debian/

Locking your source to one place lets you know where you get your bits, and limits where your traffic might go in the world. That’s a feature.

So here’s a look at one configured to use Berkeley as source. (they have a good I.T. department and work on classified stuff in the physics area, so are unlikely to have buggered sources, but also will have TLAs galore monitoring stuff. Lawrence Livermore NUCLEAR Lab was where we made our nuke stuff “go” and affiliated with Berkeley, so you know…

So why use Berkeley? Well, mostly I used it for this test as it is about 50 miles north of me and Silly Con Valley has a great metropolitan area network “MAN” on fiber at high speed. In actual production I’d be more likely to choose one that was less TLA rich and with fewer Grad Students & Wannabees potentially in charge of the repository (and with fewer Chinese Exchange Students…) like, oh, kernel.org “mirrors.edge.kernel.org”; but I didn’t see any reason to load up their servers for a TV node or for a test case. Besides, once I’m happy with it, I’m more likely to make a local repository and use an encrypted update to the local repository once a month or three instead anyway. So might was well use the public Uni for this test run example…

root@OdroidN2:/etc/apt# cat sources.list
deb https://mirrors.ocf.berkeley.edu/debian buster main contrib non-free
# deb-src http://httpredir.debian.org/debian buster main contrib non-free

deb https://mirrors.ocf.berkeley.edu/debian buster-updates main contrib non-free
# deb-src http://httpredir.debian.org/debian buster-updates main contrib non-free

deb https://mirrors.ocf.berkeley.edu/debian buster-backports main contrib non-free
# deb-src http://httpredir.debian.org/debian buster-backports main contrib non-free

deb https://mirrors.ocf.berkeley.edu/ buster/updates main contrib non-free
# deb-src http://security.debian.org/ buster/updates main contrib non-free

Here I’ve left in the commented out deb-src lines, but changed the http to https and pointed it at “mirrors.ocf.berkelely.edu/debian” for the goods.

I then tested it, and it worked fine:

root@OdroidN2:/etc/apt# apt-get update
Hit:2 https://mirrors.ocf.berkeley.edu/debian buster InRelease
Hit:3 https://mirrors.ocf.berkeley.edu/debian buster-updates InRelease
Hit:4 https://mirrors.ocf.berkeley.edu/debian buster-backports InRelease
Ign:5 https://mirrors.ocf.berkeley.edu buster/updates InRelease

I’ll note in passing that there was a hiccup on one thing, that I’d also had with the mirror director (which was why I was playing with this in the first place and figured “if I’m playing with it, might as well tighten it up”…)

404 Not Found [IP: 443]
Ign:7 http://ppa.launchpad.net/nathan-renniewaldock/flux/ubuntu focal InRelease
Err:8 http://ppa.launchpad.net/nathan-renniewaldock/flux/ubuntu focal Release
404 Not Found [IP: 80]

So something is a bit buggered on nathan-renniewaldock.

I’m not sure why I’m supposed to care… but IF I care enough I can find out:

E: The repository ‘http://ppa.launchpad.net/nathan-renniewaldock/flux/ubuntu focal Release’ does not have a Release file.
N: Updating from such a repository can’t be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

Were this a secure system that I really cared about, a followup and fix or disable would be required. As my “Roku Replacer” not so much… I did find out that the problem is not just the redirector mirror I was being directed to by the mirror redirector. It’s more generic. Nathan needs to update his stuff.

The actual upgrade also worked fine:

root@OdroidN2:/etc/apt# apt-get upgrade
Reading package lists… Done
Building dependency tree
Reading state information… Done
Calculating upgrade… Done
The following packages will be upgraded:
libldap-2.4-2 libldap-common linux-libc-dev
3 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 1479 kB of archives.

In Conclusion

So that’s pretty much it. Now my various traffic will go via my Squid Proxy Server, even if the individual application is not so configurable. Also my system updates / upgrades will run encrypted and by having a couple of model sources.list files, I can rotor them around to different places on an unpredictable basis.

Should I so choose, I can also set up a free (for a year…) VPN server on AWS and run the traffic through that. Hiding my source IP address for the Telco Router in the process and putting any traffic inside another layer of encryption / indirection.

At that point I’m well into over-kill land though. I mean really, for a system used to run the TV and post my public opinions to the internet? It would be easier to just read the blog and see what TV shows I’m complaining about ;-)

BUT, should you be in need of a bit more security in the real world, it’s nice to know you can control where your OS bits come from, that they get to you encrypted, and that nobody needs to know you are getting them or where you are.


For folks using Ubuntu, your sources list will have entries more like:

root@OdroidN2:/mmc/ext/etc/apt# cat sources.list
deb http://ports.ubuntu.com/ubuntu-ports/ bionic main restricted
deb-src http://ports.ubuntu.com/ubuntu-ports/ bionic main restricted

deb http://ports.ubuntu.com/ubuntu-ports/ bionic-updates main restricted
deb-src http://ports.ubuntu.com/ubuntu-ports/ bionic-updates main restricted

deb http://ports.ubuntu.com/ubuntu-ports/ bionic universe
deb-src http://ports.ubuntu.com/ubuntu-ports/ bionic universe
deb http://ports.ubuntu.com/ubuntu-ports/ bionic-updates universe
deb-src http://ports.ubuntu.com/ubuntu-ports/ bionic-updates universe

There is an Ubuntu mirror list here: https://launchpad.net/ubuntu/+cdmirrors

The Devuan mirror list is here: https://www.devuan.org/get-devuan

Subscribe to feed

About E.M.Smith

A technical managerial sort interested in things from Stonehenge to computer science. My present "hot buttons' are the mythology of Climate Change and ancient metrology; but things change...
This entry was posted in Tech Bits. Bookmark the permalink.

10 Responses to Tightening Debian / Devuan Update Security

  1. E.M.Smith says:

    Well, I opened an ssh window to my Proxy Server. Popped up an htop panel. Then on the Odroid N2, launched a couple of windows in the Chromium browser.

    On the Proxy Server, the process for Squid popped to the top of the list with 3.x% CPU usage. Regularly and reliably, launch a page, see it used.

    Yeah, I could go dig through logs and stuff to see exactly what’s going on, but I’m really happy enough with this as a quick check on function. It’s working. It’s a very tight couple of launch / CPU use for Squid. Nothing else is running at the moment to use Squid anyway. So now I can comfortably know that Chromium is running through the proxy server too.

  2. E.M.Smith says:

    Another interesting note:

    Launching a video on YouTube had a small use of squid, but not much. Most of the video will be in a streaming protocol, not HTTPS. Yet it looks like they do have some traffic (likely the set-up and other info) that’s going via the proxy. Odd that.


    Online video delivery uses both streaming protocols and HTTP-based protocols. Streaming protocols like Real-Time Messaging Protocol (RTMP) enable speedy video delivery using dedicated streaming servers, whereas HTTP-based protocols rely on regular web servers to optimize the viewing experience and quickly scale. Finally, a handful of emerging HTTP-based technologies like the Common Media Application Format (CMAF) and Apple’s Low-Latency HLS seek to deliver the best of both options to support low-latency streaming at scale

    So “hmmm”… Wonder if there are RMTP proxy servers? Or if I’d care… Aside from the question of what could be gained by swapping some bits in a frame of video, there’s the whole problem of doing it fast enough that there isn’t a glitch in the stream. But really, why bother?

    So OK, just “note to self” that your actual video stream will not be proxied through Squid and may need some other work (if it can be done at all).

    A quick web search shows it’s an active topic (RMTP proxy or not with things like nginx and tunneling RMTP though HTPS and more that I don’t feel like sinking time into right now… https://duckduckgo.com/?q=RMTP+proxy+server&atb=v188-6__&ia=web ) I don’t really care if someone knows I’ve got a video stream going, or that they can see the bits. After all, they can watch Star Trek Fan Movies directly if they want… BUT, were you to be doing video conferences and such, might need to dig into this more.

  3. cdquarles says:

    Here is an article discussing setting up a Squid proxy server on Windows: https://www.supportpro.com/blog/squid-proxy-installation-in-windows-server/. I see little reason why you couldn’t do that on any version of Windows. I may be wrong. Here is another article discussing setting Squid up on any version of Windows from 7 to 10: https://www.mrcnit.com/how-to-setup-squid-proxy-server-in-windows-7810-or-windows-server/.

  4. E.M.Smith says:


    Squid runs on Windows? Who knew ;-)

    I’m happy to see it as Windows folks need love too… but my last real Windows work was on XP (though I used 7 at work and saw a 10 once… ) so others will need to carry the Windows ball here.

  5. jim2 says:

    I’ve got Devuan installed, but it hasn’t been a smooth journey. I’ve tried the “live” and “desktop” Beowolf ISOs. The live won’t run from a UEFI boot. It will run from a BIOS boot. Desktop won’t run either way. In UEFI mode it throws a bunch of USB errors 71 and 110. In BIOS mode the screen is scrambled.

    Likewise, “live” throws the same errors when booted in UEFI mode. The remedies for the USB errors found so far don’t work with my machine.

  6. E.M.Smith says:

    How odd.

    Sure you got the right type of OS? (x86 vs AMD64 vs…)

    At least on my old hardware it runs fine (x86 and AMD64)

  7. jim2 says:

    It’s a brand new machine, ASUS.
    description: Desktop Computer
    product: ROG Strix GL10DH_GL10DH
    version: 1.0
    width: 64 bits
    capabilities: smbios-3.1.1 dmi-3.1.1 smp vsyscall32
    configuration: boot=normal chassis=desktop family=ROG Strix
    description: Motherboard
    product: GL10DH
    description: CPU
    product: AMD Ryzen 5 3400G with Radeon Vega Graphics
    vendor: Advanced Micro Devices [AMD]
    physical id: 28
    bus info: cpu@0
    version: AMD Ryzen 5 3400G with Radeon Vega Graphics
    slot: AM4
    size: 1563MHz
    capacity: 4200MHz
    width: 64 bits
    clock: 100MHz
    capabilities: lm fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp x86-64 constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb hw_pstate sme ssbd sev ibpb vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov succor smca cpufreq
    configuration: cores=4 enabledcores=4 threads=8

    *-generic UNCLAIMED
    description: IOMMU
    product: Advanced Micro Devices, Inc. [AMD]
    vendor: Advanced Micro Devices, Inc. [AMD]
    capabilities: msi ht bus_master cap_list

    description: USB controller
    product: Advanced Micro Devices, Inc. [AMD]
    width: 64 bits
    clock: 33MHz
    capabilities: msi msix pm pciexpress xhci bus_master cap_list
    configuration: driver=xhci_hcd latency=0
    description: USB controller
    product: Advanced Micro Devices, Inc. [AMD]
    width: 64 bits
    clock: 33MHz
    capabilities: pm pciexpress msi msix xhci bus_master cap_list
    configuration: driver=xhci_hcd latency=0
    description: USB controller
    product: Advanced Micro Devices, Inc. [AMD]
    width: 64 bits
    clock: 33MHz
    capabilities: pm pciexpress msi msix xhci bus_master cap_list
    configuration: driver=xhci_hcd latency=0

  8. E.M.Smith says:

    Ah, “brand new”… That tends to be an issue with any Linux, but the further down the food chain from the root distros the longer the issue lasts.

    I don’t KNOW that’s the issue, but that’s what I’d suspect. Probably a video driver issue for your video issue. It ought to get better over time as new drivers go into newer releases.

    IF you have an old box, like the decommissioned one you used before this one, try doing an install on it instead. If not, AND if you are feeling like spending time fiddling with Linux… You can try releases a bit further up stream to see if they have a fix already. So Debian itself. Or just downstream from Debian but where a major corporation may have fixed it up / built a driver – Ubuntu. IF they have the same issues, it’s likely a lack of hardware drivers for the newer hardware. IF they don’t have an issue, then that fix will likely show up in a Devuan update (eventually…).

    I know, not what you were hoping for. I’d said “just works for me” or something like that. I’ve not bought a new Intel Computer in years, and the last one was just an experiment with a Chromebox. Last “PC” I bought new was… an HP Laptop about 15 years ago? I live off old cheap ‘hand me downs’. Why? First off, it is incredibly cheap to do ;-) and 2nd Linux works best (has fewest new driver issues) on hardware a year or two old. (And is efficient enough that older slower hardware is very fast…)

    But were I debugging your issues, I’d look first at driver issues for new hardware.
    In particular, this caught my eye:

    *-generic UNCLAIMED
    description: IOMMU
    product: Advanced Micro Devices, Inc. [AMD]

    So an mmu IO driver is “generic UNCLAIMED”? Might be an issue…

    Then other folks look to have “had issues” with the AMD Ryzen 3400G


    Has a link it it to someone getting it going on Ubuntu and another that says:

    After a few hours googling and experimenting, I have added ‘amd_iommu=on iommu=pt’ to the kernel boot line and have not seen the issue. The ‘amd_iommu=on’ may be irrelevant since adding that alone did not have an impact.

    Given the iommu message and then this ‘fix’ that sets iommu value, I’d try that first.

  9. jim2 says:

    Thanks, CIO. For Devuan, the video and audio work great! From the error messages, it appears to be something about the USB ports. Boot goes into an interminable process of trying to configure the USB ports, with repetitive error messages. I did see an error right off the bat about the IOMMU, but didn’t find a fix. I’ll try the kernel boot line tomorrow when I have some time.

  10. jim2 says:

    I should correct that. For Devuan LIVE the audio and video work great. But if UEFI, not so much.

Comments are closed.