Q For hyper-cyber-paranoid: Text only from incoming connections?

After reading about the ways one can be hacked, even at the CPU level, I’ve become hyper-paranoid about computer security. Does anyone know if there is Linux software (or maybe hardware?) that will strip everything but text from incoming connections to a computer, ideally prepending the IP address and “WhoIs” information the the text files created/presented? I am willing to sacrifice appearance and convenience for perfect security. I suspect no one ever hacked a telegram, and that’s where I’m starting.

Hello,

To analyze data passing through your networks connections, the best way IMO is wireshark, or maybe opensnitch

I’m not sure I fully understood your need, but a look at those two different softwares could give you more hints (for you or to explain) on what kind of software you want

The only perfect security is in doing nothing.

Even without incoming connections, you still have incoming data via outgoing connections (and stateless ones, and microphones, and USB devices, and your keyboard). What you suggest would either cut you from the network, or do absolutely nothing, depending on the interpretation.

For something that might work, and is developed with a good understanding of the problems, I recommend Qubes OS.

1 Like

I have to admit I’ve been contemplating the mini with 64GB of RAM and Qubes OS. At home, I’ve pretty much shoved most of my permanent storage onto a NAS with encrypted volumes now. (It doesn’t get along well with Windows 7, alas–writes to the encrypted volumes take about six years for some reason; regular writes to the NAS are fast, writes to encrypted volumes NOT on the NAS are fast; the combo is painfully slow. If I could just get away from apps that run on Windows boxes (including ones that do NOT work through Wine, et. al…)

You can try using an air-gapped PC with strict one-way communication, for the most important things. Some links:

Discussion on Qubes forum

(only for forum Members, trust level 2+): https://forum.qubes-os.org/t/guaranteed-one-way-file-transfer-to-air-gapped-device-projects/11237.

1 Like

@MrChromebox can correct me if I am wrong, but I think that he has said before that the Intel Management Engine (IME) of modern Intel processors requires Intel networking devices in order to connect to networks. Purism laptops have non-Intel networking devices for Wifi and Ethernet. For this reason, even though the IME is disabled on Purism laptops, if it was somehow enabled it would not have networking capabilities. So the threat of CPU hacking on a Librem laptop is mitigated by this.

I would like to say that I also recommend QubesOS. I switched from a Mac a few years ago, and everything has gone well for me. You just need to read through some of the important documentation on their website and check out the QubesOS forum. There is also a YouTube playlist by SwitchedToLinux that is a few years old but still holds up and is a valuable tool to ease you into learning QubesOS.

3 Likes

Thanks dom0 and all for your responses. Definitely food for thought that will help me.

If you are going to this level, you should seriously contemplate simply disconnecting from the network - because with those restrictions a lot of things will cease to work anyway.

Ironically, only insecure connections will ever work. So you are potentially degrading your security and privacy. Or were you only applying this restriction at a higher level in the protocol stack? e.g. only to the application payload? Or what level in the protocol stack? But then if you only restrict at the application level, you expose yourself to bugs like Heartbleed.

It is likely that with those restrictions you would not be able to apply software updates (not directly anyway) and that too could degrade your security.

Limiting yourself to text only protocols could still allow some server software to work - but then if those servers have bugs, you could still be compromised. However with the the additional requirement of “prepending IP address and whois info” then basically no server software will work and there will be no incoming text. (OK, the echo and discard servers / protocols might still be usable - and syslog too if you don’t worry about the message structure.)

So the only way that you would get any incoming text is if you run custom communication protocols (and your interlocutors run the same). So you may get lonely. :wink:

I wasn’t entirely clear on the nature of the computer to be protected but if it is non-portable then I would consider doing this in intervening network equipment (i.e. running Linux) and it should be doable.

You will also need to define what you mean by “incoming connection”. Does it mean “inbound TCP connection”, in which case, you can mostly firewall out all such connections on a computer that is not intended to be a server? However that won’t deal with hardware level exploits. Does it mean “all incoming packets”? (hence TCP will not work at all)

1 Like

Comment out every entry from your services file exccept TELNET? I think every computer has some form of a “services” file (unless it has been deprecated).

I have a 30 year old HP3000 that has been on the internet for 20 years (off and on). I allow only FTP and TELNET. (SSH was never ported to it, the O/S is too old.)

You can get a text prompt that says EMPIRECLASSIC if you telnet to empire.game-host.org

My sample services file below:

#This file contains the information about the services provided.
#Copy this file to SERVICES.NET.SYS if that file does not already exist.
#
# The form for each entry is:
# <official service name>    <port number/protocol name>    <aliases>
#
# See the Configuring and Managing MPE/iX Internet Services Manual
# for more information (HP Part No. 32650-90835).
#
# Note: The entries cannot be preceded by a blank space.
#
#
#echo           7/tcp                 # Echo
#echo           7/udp                 #
#discard        9/tcp  sink null      # Discard
#discard        9/udp  sink null      #
#daytime       13/tcp                 # Daytime
#daytime       13/udp                 #
#chargen       19/tcp  ttytst source  # Character Generator
#chargen       19/udp  ttytst source  #
ftp           21/tcp
telnet        23/tcp
#smtp          25/tcp                  #Sendmail
#time          37/tcp  timeserver     # Time
#time          37/udp  timeserver     #
#domain        53/tcp  nameserver     # Domain Name Service
#domain        53/udp  nameserver     #
#bootps        67/udp                 # Bootstrap Protocol Server
#bootpc        68/udp                 # Bootstrap Protocol Client
#tftp          69/udp                 # Trivial File Transfer Protocol
#nmbp         137/udp
#smbp         139/tcp
#DAServer     987/tcp                 # SQL distributed access
#klogin       543/tcp                 # Kerberos rlogin -kfall
#kshell       544/tcp  krcmd          # Kerberos remote shell -kfall
#ekshell      545/tcp  krcmd          # Kerberos encrypted remote shell
#kerberos    5750/udp  kdc            # Kerberos (server) udp -kfall
#kerberos    5750/tcp  kdc            # Kerberos (server) tcp -kfall
#krbupdate    760/tcp  kreg           # Kerberos registration -kfall
#kpasswd      761/tcp  kpwd           # Kerberos "passwd" -kfall
#eklogin     2105/tcp                 # Kerberos encrypted rlogin -kfall
#ntp          123/udp
#kerberos5     88/udp  kdc
#gns         3000/tcp
#syslog      514/udp                  #Syslog daemon'
#klogin       543/tcp                 # Kerberos rlogin -kfall
#kshell       544/tcp  krcmd          # Kerberos remote shell -kfall
#ekshell      545/tcp  krcmd          # Kerberos encrypted remote shell
#kerberos    5750/udp  kdc            # Kerberos (server) udp -kfall
#kerberos    5750/tcp  kdc            # Kerberos (server) tcp -kfall
#krbupdate    760/tcp  kreg           # Kerberos registration -kfall
#kpasswd      761/tcp  kpwd           # Kerberos "passwd" -kfall
#eklogin     2105/tcp                 # Kerberos encrypted rlogin -kfall
#kerberos5     88/udp  kdc
#diagmond    1508/tcp                 # Support Tools Manager (STM/iX)
#syslog       514/udp                 # Syslog
#psmond      1788/tcp

I meant to add: That, in and of itself, is a security exposure. It means that you have to interact with a whois server and it is a potential avenue for network-based exploit (if your whois client is crappy).

For the hyper paranoid, you would

a) whitelist specific IP addresses and block everything else

b) before adding an IP address to the whitelist, which would be a manual process, you would investigate the IP address manually on another computer.

Be aware though that IP addresses can be forged, depending on whom you trust and whether other parties are preventing forgery. (As an example of this, if you took your hyper paranoid equipment to a cafe and used their free WiFi and if you have no reason to trust the operator of the cafe then almost all the IP addresses that you see could be bogus. So if your attacker knew any IP addresses that you had whitelisted then your whitelist could be bypassed.)

I would guess that that file is used only for mapping names to numbers.

I can’t swear that a service will fail to start / succeed in starting depending on whether it is absent / present in /etc/services but I would expect that file to be ignored.

There was a time when inetd.conf was the place to define what services would start automatically if a TCP connection were received on a given port number. That, I think, is dependent on /etc/services.

However inetd is I believe deprecated. These days servers should be being started by systemd on the basis of a .service file.

Hmmm. As telnet is by default insecure, most people would consider it deprecated, and not to be used in any environment even where the level of paranoia is much lower than “hyper”. :wink:

I wouldn’t allow it from the internet. It may be acceptable internally. Even then I always just use ssh.

So, as you say, only to be used where ssh is not available - and only then if you understand and accept the risk of using an insecure protocol.

As the services file was read by inetd, if its usage got passed to systemd, my system wouldn’t know. Although I wonder if folks are still upset by the switch to systemd and are still forking away from it?

I presume you did read the part I said my system is so old it doen’t have ssh? And it never shall it seems. It could have been ported, with the same difficulty it takes to port any other *nix program, no one was willing to do it. In big biz, it was easier to put an SSH translation to telnet server in the middle. However my server is in my garage and I don’t have the funds for that. But since all it does is run text games, I don’t care if anyone steals someone elses “pick up weapon”, or “go north” commands.

Yes telnet is insecure, albeit the title of this thread did say text only. Just throwing my experiences out there, even if they are old.

By the way, there are the open log ins on my system, if you use something like PUTTY for telnet, destructive backspace is preferred.

HELLO PLAYER.EMPIRE1
HELLO PLAYER.EMPIRE2
HELLO PLAYER.EMPIRE3
HELLO PLAYER.EMPIRE4
HELLO PLAYER.EMPIRE5
HELLO PLAYER.MANSION
HELLO PLAYER.WARP
HELLO PLAYER.ADVENT
HELLO PLAYER.FEUDAL
HELLO PLAYER. TRIREME
HELLO PLAYER.CIVIL
HELLO PLAYER.TREK
HELLO PLAYER.SUPRTRK
HELLO PLAYER.SUPRTREK

(below requires HP terminal emulation)
HELLO PLAYER.MILLBORN
HELLO PLAYER.DROID
HELLO PLAYER.ZONE

(and zone requires set up by me.)