• 0 Posts
  • 274 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle




  • Everything was harder back then - even when using Windows. But you had to be a real masochist to run Linux.

    Computers were still quite new that most people had no real use for them beyond “work things”. Only nerds really used them for anything else. “Do you have an email address” isn’t a question you ask today.

    “Kids these days” don’t realize how easy they have it when it comes to just general comparability. There weren’t a lot of standards yet and vendors had proprietary drivers and offered no support AT ALL for “lye nux”. You had to do a ton of research and fiddling to figure out if there was any support for your specific version of a specific chip used by any peripheral you used. And then to discover that you had to patch your kernel to add a driver that somebody had bodged together. So now you were running your own fun custom-kernel so you could get full-duplex rather than simplex audio! But it works!

    Like - lets say today you want to buy an external IDE drive controller to plug in some old drives to for backup. You to to Amazon, search “USB external IDE enclosure” and buy the cheapest one you find. It probably works unless it’s defective. In '95 USB and Firewire were in their infancy so you would probably buy a serial or parallel port device. You would need to find whether Linux supported the specific version of the thing you wanted to buy, what tools there would be for it, etc. There was no standard “bulk storage device” driver that you could rely on or hope the vendor would implement. Even if you were an early adopter and got a USB or Firewire device it might have some “basic” functionality that works with OSS drivers but you couldn’t use all of it.

    Vendors back then also shipped their own software with things, not just drivers. It was always just the absolute worst crap that was buggy as shit. But it would do a lot of the heavy lifting in working with their device. Like any Creative Labs audio player you wanted to get working. Sure it used USB but it didn’t just mount as storage device, you needed to use the worst GUI ever put before mankind to use it (under Windows). Under Linux you had to find a specific tool that would support pushing/pulling media from it. These days it would just mount as a drive automatically and you’d use standard desktop tools to interact with it.

    Even with DOS/Windows you’d buy a game and as you came home from the store with it in a box wonder “will this work on my computer and how long will I need to mess with it?” I had to configure a specific CD-ROM driver to be used by DOS just to run Tie Fighter vs. X-Wing for example. Had a special boot floppy just for that game since that driver didn’t work with literally anything else I had.

    Hardware just generally didn’t “auto configure”. “Plug 'n Play” was still very much in its infancy and you often had to manually configure hardware and install special drivers just for a particular card or peripheral.

    IRQ 7 DMA 220. I probably just triggered some folks. If you were setting up a “Sound Blaster or compatible” then you had to know what interrupt it used (7) and what address it was on on the direct-memory bus (220). And you hoped there wasn’t a conflict with something else. If there was then there would be a DIP switch you could use to change the base memory address or IRQ from the default. But you were telling your software where to find the card.

    USB was a f’ing game changer for peripherals. Serial and parallel ports were so slow and obnoxious to use. Before that there was no real way to “probe” the bus to discover what was there unless you knew exactly what you were looking for (there’s no lsusb for serial ports). So you just guessed at the driver you need and “modprob foo” hoping it worked.

    It’s amazing what 20ish years of just developing standards has done.

    If you want a taste of that world I highly recommend LGR on YouTube. He’s mostly Windows focused but look for videos where he tries out “oddware” to see how often he has trouble getting things to work on period hardware using the vendor-supplied software even. Then multiply that by 100x for Linux. :-)










  • Put your reverse proxy in a DMZ, so that only it is directly facing the intergoogles

    So what? I can still access your application through the rproxy. You’re not protecting the application by doing that.

    Install a single wildcard cert and easily cover any subdomains you set up

    This is a way to do it but not a necessary way to do it. The rproxy has not improved security here. It’s just convenient to have a single SSL endpoint.

    There’s even nginx configuration files out there that will block URL’s based on regex pattern matches for suspicious strings. All of this (probably a lot more I’m missing) adds some level of layered security.

    If you do that, sure. But that’s not the advice given in this forum is it? It’s “install an rproxy!” as though that alone has done anything useful.

    For the most part people in this form seem to think that “direct access to my server” is unsafe but if you simply put a second hop in the chain that now you can sleep easily at night. And bonus points if that rproxy is a VPS or in a separate subnet!

    The web browser doesn’t care if the application is behind one, two or three rproxies. If I can still get to your application and guess your password or exploit a known vulnerability in your application then it’s game over.


  • My reverse proxy setup allows me to map hostnames to those services and expose only 80/443 to the web,

    The mapping is helpful but not a security benefit. The latter can be done with a firewall.

    Paraphrasing - there is a bunch of stuff you can also do with a reverse proxy

    Yes. But that’s no longer just a reverse proxy. The reverse proxy isn’t itself a security tool.

    I see a lot of vacuous security advice in this forum. “Install a firewall”, “install a reverse proxy”, etc. This is mostly useless advice. Yes, do those things but they do not add any protection to the service you are exposing.

    A firewall only protects you from exposing services you didn’t want to expose (e.g. NFS or some other service running on the same system), and the rproxy just allows for host based routing. In both cases your service is still exposed to the internet. Directly or indirectly makes no significant difference.

    What we should be advising people to do is “use a valid ssl certificate, ensure you don’t use any application default passwords, use very good passwords where you do use them, and keep your services and servers up-to-date”.

    A firewall allowing port 443 in and an rproxy happily forwarding traffic to a vulnerable server is of no help.