Off-and-on trying out an account over at @tal@oleo.cafe due to scraping bots bogging down lemmy.today to the point of near-unusability.

  • 17 Posts
  • 891 Comments
Joined 2 years ago
Cake day: October 4th, 2023
  • tal@lemmy.todaytoSelfhosted@lemmy.world•[Solved] OpenWrt & fail2banEnglish
    2·
    1 day ago

    You would typically want to use static ip addresses for servers (because if you use DHCP the IP is gonna change sooner or later, and it’s gonna be a pain in the butt).

    In this case, he controls the local DHCP server, which is gonna be running on the OpenWRT box, so he can set it to always assign whatever he wants to a given MAC.

  • tal@lemmy.todaytoSelfhosted@lemmy.world•[Solved] OpenWrt & fail2banEnglish
    1·
    1 day ago

    except that all requests’ IP addresses are set to the router’s IP address (192.168.3.1), so I am unable to use proper rate limiting and especially fail2ban.

    I’d guess that however the network is configured, you have the router NATting traffic going from the LAN to the Internet (typical for a home broadband router) as well as from the home LAN to the server.

    That does provide security benefits in that you’ve basically “put the server on the Internet side of things”, and the server can’t just reach into the LAN, same as anything else on the Internet. The NAT table has to have someone on the LAN side opening a connection to establish a new entry.

    But…then all of those hosts on the LAN are going to have the same IP address from the server’s standpoint. That’s the experience that hosts on the Internet have towards the same hosts on your LAN.

    It sounds like you also want to use DHCP:

    Getting the router to actually assign an IP address to the server was quite a headache

    I’ve never used VLANs on Linux (or OpenWRT, and don’t know how it interacts with the router’s hardware).

    I guess what you want to do is to not NAT traffic going from the LAN (where most of your hardware lives) and the DMZ (where the server lives), but still to disallow the DMZ from communicating with the LAN.

    considers

    So, I don’t know whether the VLAN stuff is necessary on your hardware to prevent the router hardware from acting like a switch, moving Ethernet packets directly, without them going to Linux. Might be the case.

    I suppose what you might do — from a network standpoint, don’t know off-the-cuff how to do it on OpenWRT, though if you’re just using it as a generic Linux machine, without using any OpenWRT-specific stuff, I’m pretty sure that it’s possible — is to give the OpenWRT machine two non-routable IP addresses, something like:

    192.168.1.1 for the LAN

    and

    192.168.2.1 for the DMZ

    The DHCP server listens on 192.168.1.1 and serves DHCP responses for the LAN that tell it to use 192.168.1.1 as the default route. Ditto for hosts in the DMZ. It hands out addresses from the appropriate pool. So, for example, the server in the DMZ would maybe be assigned 192.168.2.2.

    Then it should be possible to have a routing table entry to route 192.168.1.1 to 192.168.2.0/24 via 192.168.2.1 and vice versa, 192.168.2.1 to 192.168.1.0/24 via 192.168.1.1. Linux is capable of doing that, as that’s standard IP routing stuff.

    When a LAN host initiates a TCP connection to a DMZ host, it’ll look up its IP address in its routing table, say “hey, that isn’t on the same network as me, send it to the default route”. That’ll go to 192.168.1.1, with a destination address of 192.168.2.2. The OpenWRT box forwards it, doing IP routing, to 192.168.2.1, and then that box says “ah, that’s on my network, send it out the network port with VLAN tag whatever” and the switch fabric is configured to segregate the ports based on VLAN tag, and only sends the packet out the port associated with the DMZ.

    The problem is that the reason that home users typically derive indirect security benefits from use NAT is that it intrinsically disallows incoming connections from the server to the LAN. This will make that go away — the LAN hosts and DMZ hosts will be on separate “networks”, so things like ARP requests and other stuff at the purely-Ethernet level won’t reach each other, but they can freely communicate with each other at the IP level, because the two 192.168.X.1 virtual addresses will route packets between each the two networks. You’re going to need to firewall off incoming TCP connections (and maybe UDP and ICMP and whatever else you want to block) inbound on the 192.168.1.0/24 network from the 192.168.2.0/24 network. You can probably do that with iptables at the Linux level. OpenWRT may have some sort of existing firewall package that applies a set of iptables rules. I think that all the traffic should be reaching the Linux kernel in this scenario.

    If you get that set up, hosts at 192.168.2.2, on the DMZ, should be able to see connections from 192.168.1.2, on the LAN, using its original IP address.

    That should work if what you had was a Linux box with three Ethernet cards (one for each of the Internet, LAN, and WAN) and the VLAN switch hardware stuff wasn’t in the picture; you’d just not do any VLAN stuff then. I’m not 100% certain that any VLAN switching fabric stuff might muck that up — I’ve only very rarely touched VLANs myself, and never tried to do this, use VLANs to hack switch fabric attached directly to a router to act like independent NICs. But I can believe that it’d work.

    If you do set it up, I’d also fire up sudo tcpdump on the server. If things are working correctly, sudo ping -b 192.168.1.255 on a host on the LAN shouldn’t show up as reaching the server. However, ping 192.168.2.2 should.

    You’re going to want traffic that doesn’t match a NAT table entry and is coming in from the Internet to be forwarded to the DMZ vlan.

    That’s a high-level of what I believe needs to happen. But I can’t give you a hand-holding walkthrough to configure it via off-the-cuff knowledge, because I haven’t needed to do a fair bit of this myself — sorry on that.

    EDIT: This isn’t the question you asked, but I’d also add that what I’d probably do myself if I were planning to set something like this up is get a small, low power Linux machine with multiple NICs (well, okay, probably one NIC, multiple ports). That cuts the switch-level stuff that I think that you’d likely otherwise need to contend with out of the picture, and then I don’t think that you’d need to deal with VLANs, which is a headache that I wouldn’t want, especially if getting it wrong might have security implications. If you need more ports for the LAN, then just throw a regular old separate hardware Ethernet switch on the LAN port. You know that the switch can’t be moving traffic between the LAN and DMZ networks itself then, because it can’t touch the DMZ. But I don’t know whether that’d make financial sense in your case, if you’ve already got the router hardware.

  • tal@lemmy.todaytoTechnology@lemmy.world•Race for AI is making Hindenburg-style disaster ‘a real risk’, says leading expertEnglish
    1·
    1 day ago

    You can get wrong answer with 100% token confidence, and correct one with 0.000001% confidence.

    If everything that I’ve seen in the past has said that 1+1 is 4, then sure — I’m going to say that 1+1 is 4. I will say that 1+1 is 4 and be confident in that.

    But if I’ve seen multiple sources of information that state differing things — say, half of the information that I’ve seen says that 1+1 is 4 and the other half says that 1+1 is 2, then I can expose that to the user.

    I do think that Aceticon does raise a fair point, that fully capturing uncertainty probably needs a higher level of understanding than an LLM directly generating text from its knowledge store is going to have. For example, having many ways of phrasing a response will also reduce confidence in the response, even if both phrasings are semantically compatible. Being on the edge between saying that, oh…an object is “white” or “eggshell” will also reduce the confidence derived from token probability, even if the two responses are both semantically more-or-less identical in the context of the given conversation.

    There’s probably enough information available to an LLM to do heuristics as to whether two different sentences are semantically-equivalent, but you wouldn’t be able to do that efficiently with a trivial change.

  • tal@lemmy.todaytoHardware@lemmy.world•Microsoft's new 10,000-year data storage medium: glassEnglish
    6·
    1 day ago

    One major problem with very-long-term-data-retention formats is that the hardware to read the things may not be around in a surprisingly short period of time. Like, if you assume that this format isn’t bumping up against fundamental physical limits, then it will probably be supplanted down the line by something else, and people will probably stop making the devices to work with them before long. The devices to work with the media won’t last as long as the media, and there probably won’t be new ones produced.

    https://en.wikipedia.org/wiki/BBC_Domesday_Project#Concerns_over_electronic_preservation

    The BBC Domesday Project was a partnership between Acorn Computers, Philips, Logica, and the BBC (with some funding from the European Commission’s ESPRIT programme) to mark the 900th anniversary of the original Domesday Book, an 11th-century census of England. It has been cited as an example of digital obsolescence on account of the physical medium used for data storage.[1][2][3][4]

    This new multimedia edition of Domesday was compiled between 1984 and 1986 and published in 1986.

    In 2002, concerns emerged over the potential unreadablility of the discs as computers capable of reading the format became rare and drives capable of accessing the discs even rarer.[14][15] Aside from the difficulty of emulating the original code, a major issue was that the still images had been stored on the laserdisc as single-frame analogue video, which were overlaid by the computer system’s graphical interface. The project had begun years before JPEG image compression and before truecolour computer video cards had become widely available.

    I think that realistically, if you want to maintain something for very long-term archival use, it’s probably going to need to be rolled over into a new format periodically.

  • tal@lemmy.todaytoTechnology@lemmy.world•The RAM shortage is coming for everything you care aboutEnglish
    20·
    2 days ago

    Our last, best hope for the subsidy model was Valve, a company that famously rakes in money hand over fist and launched the original Steam Deck at the unbeatable price of $399 through a “painful” amount of subsidy. If Valve did the same for the upcoming Steam Machine, it could have legitimately competed with the PlayStation and Xbox for your living room TV.

    But Valve has all but dashed those hopes through a series of moves. In late December, it discontinued the $399 Steam Deck, raising the starting price to $549. In early February, it announced that the Steam Machine had been delayed due to the memory shortage and that the company would have to reset expectations on pricing. And now, even the $549 Steam Deck OLED is out of stock specifically because of the memory crisis.

    I was pretty confident that Valve was not going to subsidize the Steam Machine from the start, even before Valve said that it would be priced comparably to a PC and even before it said that it was delaying determining pricing (which was a good sign that it hadn’t locked in a contract price on components). I commented along those lines here.

    Consoles can do the razor-and-blades model because they are a closed platform. If you buy a Playstation, it doesn’t do you much good unless you use it to buy Playstation games. So each Playstation purchase is very, very probably going to be used to purchase Playstation games. Sony can crank up prices on those and make their initial loss back.

    But the Steam Machine is open. I can go run whatever on it. I can just take the thing and, say, make it a media server or whatever. And if Valve subsidizes it, people will just buy it instead of a comparable PC and then run whatever they want on it. Doesn’t make much sense for Valve, just because of the nature of the machine.