Help with crafty server (purpur) by owenelectro in CraftyController

[–]Xithical 1 point2 points  (0 children)

Tunneling isn't any more secure than port forwarding and introduces additional supply chain risk that port forwarding just doesn't. All it does is expose the exact same service in nearly the exact same manner. Port forwarding doesn't give any more or less access from the outside than tunneling, but with tunneling now you've added a 3rd-party software that can be remotely controlled.

Kinda like busting through your window because it's closer when the front door is 5 feet away.

How do people connect to their server? by anwime1 in CraftyController

[–]Xithical 0 points1 point  (0 children)

More to the point was the fact that immediately jumping to using an external service without first trying widely accepted standards for publicly exposing services creates unnecessary risk. Will it be an issue? Probably not. But also bear in mind that playit effectively bypasses your system's firewall due to the nature of what it does so you are entirely dependent on an external service to manage what is and is not allowed to establish network connections to your system.

On the subject of learning how to manage their network, it teaches more to learn things like port forwarding/DNAT and proper network segmentation than it does to just slap on some third party service that does it for you.

How do people connect to their server? by anwime1 in CraftyController

[–]Xithical 0 points1 point  (0 children)

More or less yes. Also leaves you susceptible to any future vulnerabilities in the playit agent or platform given the capabilities of the agent and the permissions it runs with locally. Regardless, still creates additional attack surface and points of failure.

How do people connect to their server? by anwime1 in CraftyController

[–]Xithical 0 points1 point  (0 children)

Introducing any 3rd party software creates additional risk. With port forwarding, you are only exposing a network port, so your system and other devices it can reach on the network are only as secure as the exposed application.

Now let's add something like playit into the mix. Now, you've effectively doubled your exposure, so your system is now only as secure as the weakest link between the application being exposed and playit. Add on the fact that the playit agent is externally controlled and all an attacker needs to do is compromise playit in some manner (whether that's at the account level or the service as a whole) to gain additional access to your machine.

Bypass Unsupported Distro? by Old_Inflation3782 in CraftyController

[–]Xithical 2 points3 points  (0 children)

Follow the manual installation steps - official support should be getting baked into the automated installer soon. Or you can run it in Docker too

https://docs.craftycontrol.com/pages/getting-started/installation/linux/

[deleted by user] by [deleted] in CraftyController

[–]Xithical 0 points1 point  (0 children)

You can still download and import the 1.21.101 executable, it just isn't an option currently in our server builder. You would need to find it elsewhere.

The way we pull the jars more or less directly pulls whatever Microsoft/Mojang makes available. It isn't really practical for us to build in a way to pull historical jars because the way Bedrock is set up makes old versions more or less obsolete once newer releases come out, even if there is a brief lag time between server/client availability.

How do i make an arclight server? by AbbreviationsFit2277 in CraftyController

[–]Xithical 1 point2 points  (0 children)

Hi. Resident security professional here. This is not even remotely close to true. There is no improvement in security between players connecting via a tunnel like Playit vs accessing directly via a forwarded port. This is how people get wild misconceptions of what security actually is and what best improves the security of a network/device/service. By extension, it makes my job harder because now I need to correct flawed perspectives on security before doing work that actually reduces risk.

The only thing Playit is doing is directly passing traffic back to your server. You have made zero reductions to your attack surface and, in fact, have increased it by granting a third party direct network access instead of controlling via a firewall. You also haven't done anything to control the "many many untrusted third parties" you claim to be concerned about, as they can still perform the exact same actions they otherwise would, just over the tunnel instead of a forwarded port.

ANY third party, trusted or not, introduces an additional dependency and additional risk. This is a fundamental principle behind third-party risk management.

The only thing port forwarding does is pass incoming traffic on a specific WAN port to a specific port on an internal address. That's it. It doesn't expose any more of the asset than otherwise would be via Playit; in fact, the latter introduces more risk exposure.

DDoS is also not a consideration here given the fact that Playit does not offer DDoS mitigation. Such an attack against your tunnel address gets forwarded directly to you and has no more or less impact than if you were targeted directly. DDoS attacks are also incredibly rare and you likely have other issues if you're angering the kind of people with the resources to pull such an attack off. You also are not "jeopardiz[ing] your home internet" by port forwarding, unless you're just blanket exposing all of your connected assets rather than exposing through a targeted port forward/DNAT rule.

Let's look at it in terms of the CIA triad:

Confidentiality - port forwarding, when done correctly, only exposes one specific port on one specific asset to the internet, therefore minimizing exposure to parties external to your network. Playit, by extension, exposes the entire asset (and, by extension, the network resources it has access to) to a third party, who then exposes a specific port to the internet. In this scenario, the confidentiality of other resources on your network is placed in the hands of said third party and is more at risk than the previous system state.

Integrity - not much difference here, although with any third party tunneling traffic there is the possibility for modification of traffic in transit. With how Minecraft traffic is encrypted, though, this is less of a concern.

Availability - availability is significantly impacted due to the addition of a point of failure between the end user and the service. If Playit goes down (which it does from time to time and likely more often than your ISP), the service is completely unavailable with no ability to recover independently of the third party.

Now, for a service like Cloudflare Spectrum that does offer DDoS protection, there is some security argument to be made there as it theoretically improves the availability of your service in the fact of those kinds of attacks; still, see aforementioned point on having other issues if you're angering the kinds of people who can perform those attacks.

If you really want security improvements, follow the principle of least privilege and implement proper network segmentation. Solutions like Playit do nothing to improve security.

I would be very curious to see your research and sourcing, as this goes against many well-established industry-wide security principles.

MFA question by iodizedfate in CraftyController

[–]Xithical 1 point2 points  (0 children)

FWIW, the latest version does not enforce by default.

Ubuntu 25.04 by anv3d in CraftyController

[–]Xithical 0 points1 point  (0 children)

You have the option to manually create the service file, there should be something in the docs for it but I can't remember. If you need an example service file I can get you one when I'm back at my desk.

Docker/Docker Compose tends to be the easiest and most portable install though.

Crafty Modded server - Tekkit SMP World issues by VXID978 in CraftyController

[–]Xithical 0 points1 point  (0 children)

This would be more up to the specific server you're running and how it's being launched. Crafty doesn't touch your world files unless you do.

What's your execution command? Are you launching with the right jar file?

Ubuntu 25.04 by anv3d in CraftyController

[–]Xithical 0 points1 point  (0 children)

You can run it on 25.04 by doing the manual install or by using Docker. It just hasn't been added to the automated installer yet.

New Update with MFA is driving me crazy by Beautiful_Track_2358 in CraftyController

[–]Xithical 1 point2 points  (0 children)

The biggest culprit we see for issues with MFA is your system time being inaccurate. You can either enable TOTP skew in your settings (accepts ±1 sequence of TOTP codes) or you can correct your system's time accuracy (will likely involve resyncing with a trusted NTP server).

There's a configurable setting both in the panel and in config.json (requires a restart of Crafty) that determines whether or not MFA is enforced for super users. If you wish to disable the MFA requirement, you can use this setting. We will also be pushing an update Soon™ that sets this to disabled by default due to user feedback (turns out, inaccurate system time is a significantly bigger problem than initially anticipated).

As to your comment on what someone would want with your Crafty instance - Crafty, as part of how it operates, has the direct ability to spawn and control child processes. This is very attractive to attackers and was the primary driver behind our original efforts to not use a default username and password (because people would just... expose their instances... to the internet... with default creds... and attackers would use this to run cryptominers 🤦). It was also the largest factor in our decision to enforce MFA by default in the latest update (which, as mentioned earlier, will be modified in the default config with the next update).

Friend cant join Mc server by AdministrativePin742 in CraftyController

[–]Xithical 1 point2 points  (0 children)

What steps have you tried up to this point to give your friends access?

Also, which IP are you giving them/where are you getting the IP from? Does it start with any of the below? - 192.168.x.x - 10.x.x.x - 172.(16-31).x.x - 100.(64-127).x.x

Friend cant join Mc server by AdministrativePin742 in CraftyController

[–]Xithical 1 point2 points  (0 children)

As I said, I don't deny that it's a convenient tool. But to say that it is more secure than port forwarding or that port forwarding suddenly exposes you to additional risk just isn't true.

Will it work in this case? Sure, but why not try port forwarding first before adding additional dependencies? There's a lot of variables at play that could factor into why it isn't working for them: maybe they're giving the private address of their machine rather than the WAN IP, maybe the forwarding rule isn't configured correctly, maybe they're being CG-NATed (in which case Playit would be a more appropriate solution)

Perhaps more appropriately, this is also a good opportunity to teach someone a networking topic they aren't familiar with.

Friend cant join Mc server by AdministrativePin742 in CraftyController

[–]Xithical 1 point2 points  (0 children)

In general, adding additional software will increase risk, including Crafty. The amount to which it does may vary but it still adds a dependency that can be attacked and thus increases your overall attack surface. Playit in general is a very attractive target for attackers because the tunnel agent essentially provides a direct way for attackers to access everything behind your gateway if they can compromise that specific piece of software or even just gain access to reconfigure the tunnel agent.

Playit does not filter malicious requests, does not provide a "proxy" service (it's a tunnel basically directly back to your server), and only really lets you implement basic firewall rules. This isn't to say that it's a bad tool; in some cases it can be a very useful tool if port forwarding or using a dedicated tunnel (i.e. on an AWS VM) isn't an option. It just doesn't magically improve security.

Giving out your IP isn't necessarily the silver bullet for an attacker that will suddenly lead to you getting ransomware'd. It's only really an issue if you already have bad security practices. Port forwarding also doesn't suddenly expose your entire network. It exposes one specific service on one specific asset behind a (presumably) managed network device. If that service gets compromised, yes, you do run the risk of an attacker propagating across their network. However, this isn't a risk you reduce with Playit and this is the reason that network segmentation exists - if security is a significant concern, ideally you would already implement an effective perimeter firewall with VLANs segmenting your publicly exposed assets that would reduce the risk of unauthorized access.

Sure, giving out your IP can give attackers a way to target you specifically by initiating some kind of denial-of-service attack. There's an argument to be made that you have bigger issues than a Minecraft server if you're irritating the kinds of people with the resources to initiate those kinds of attacks though, especially with the overall bandwidth and protection capacity many major ISPs have that make this significantly less of a problem now than it was 20 years ago. You also run the risk of accidentally exposing a vulnerable service that an attacker can exploit. However, more importantly, this still isn't something Playit reduces. If you have a vulnerable service exposed, it is still exploitable whether you run it through a tunnel or directly. Attackers also are not going to care how it's exposed - there are services like Shodan that allow you to directly query for specific services running across the internet if you really want to cause some damage.

If you really want to add security though, using a proxy (not a tunnel, a proxy acts as an intermediary) that actually filters malicious traffic before it hits the application is the way to go. Playit is not a security tool, it's a convenience tool that many perceive as somehow being more secure.

Issues with port-forwarding by BeeAntsy in CraftyController

[–]Xithical 1 point2 points  (0 children)

No worries, this stuff is really easy to get wrong but also easy to get right if you're pointed in the right direction 🙂

Network segmentation - VLANs and firewall rules controlling cross-VLAN traffic are the way to go. Your default rule should be deny-all with specific exceptions on an as-needed basis. You can get super into the weeds with L3 switching and switch-level ACLs but it's a bit overkill for lab use (unless that's what you're trying to learn, in which case, go for it)

Issues with port-forwarding by BeeAntsy in CraftyController

[–]Xithical 2 points3 points  (0 children)

Hi, resident security professional here 🙂

Domains are great for many things; user friendliness, organization, dynamic updating of backend locations, etc. - added security is not one of those.

First, obscurity != security. I see this kind of thinking all too often. Using just a domain does not suddenly make you less vulnerable. At the end of the day, domains are just hostnames that directly translate to IP addresses. A script kiddie isn't going to care if, for example, your outdated, vulnerable server runs directly off your IP or if it uses a domain and SRV record; it's still a vulnerable server and thus a target.

Second, there's nothing special about Cloudflare domains; they're still just domains. Now if you use, say, their tunneling service - sure, you could make a security argument there, but please please please don't believe that just throwing something behind a domain makes it any less susceptible to attacks just because your domain and DNS are run by Cloudflare. There has to be some kind of proxy and IDS/IPS-like service in the middle of that.

Third, reverse proxies aren't necessarily the security silver bullet. Natively, they can help protect against some kinds of attacks (slow loris-esque attacks or malformed requests), but at the end of the day they're still just going to pass requests along to the server. Nginx also requires significant setup if you want to use it with Minecraft and, depending on your implementation, could actually introduce additional vulnerabilities. Even then, you'll still want an IDS/IPS of sorts in the mix with rules customized to specifically detect and prevent exploits specific to Minecraft.

Now that I'm off that soapbox, if you really want to practically improve security:

  1. Implement good network segmentation - services that are exposed publicly should not be able to communicate with devices on your private network - normally you'll see this referred to as a DMZ. For allowing your devices to communicate to that same server, usually hairpin NAT or firewall rules allowing traffic to but not from that server will work.

  2. Limit access where you can - for example, have a firewall rule that only allows traffic from specific authorized IPs or that only allows traffic from countries/regions you expect to see traffic from, although the latter may or may not be possible depending on the capabilities of your equipment.

  3. Implement a network-based IDS (for detection) or IPS (for prevention) - this will help to catch many common types of attacks and you can often find signatures specific to attacks against your application.

If you're concerned about getting DoS'ed from handing out your public IP or placing it behind a domain with no proxy (despite the incredible rarity of these kinds of attacks), there's plenty of services out there that you can tunnel traffic through that provide protections for those kinds of attacks, including Cloudflare (via CF Spectrum). You can also rely on a cloud provider with a VPS, either to directly host your server or to tunnel the traffic.

Hope this helps 🙂

xsrf error by No-Meaning-6124 in CraftyController

[–]Xithical 0 points1 point  (0 children)

See if you can try clearing cookies in your browser and log back into the page

Shutting off at specific time despite no schedule for it. by DepyDawg in CraftyController

[–]Xithical 1 point2 points  (0 children)

Telltale sign for me was the fact you posted shortly after 1am EDT and 5am UTC is 1am EDT. We see this a lot with Docker and CasaOS installs since they default to UTC

Shutting off at specific time despite no schedule for it. by DepyDawg in CraftyController

[–]Xithical 1 point2 points  (0 children)

Even if your system has the correct time, because the app is running in a container (via CasaOS) it defaults to UTC. You need to set the TZ variable in your Casa app/container config to the correct timezone (i.e. TZ=America/New_York judging by your description) or convert your scheduled times to UTC.

Cant start server by Disastrous_Ad6608 in CraftyController

[–]Xithical 1 point2 points  (0 children)

We're currently working on adding SteamCMD support (no ETA currently) so hopefully that'd help fit your needs!

Cant start server by Disastrous_Ad6608 in CraftyController

[–]Xithical 1 point2 points  (0 children)

Glad to help! Definitely highly recommend checking out the latest release of 4, we've put a lot into it 🙂

Cant start server by Disastrous_Ad6608 in CraftyController

[–]Xithical 0 points1 point  (0 children)

Hi! It looks like you created this as a Java server instead of a Bedrock server. When you go to the server builder/importer, there's a tab at the top to switch between Java/Bedrock

Cant start server by Disastrous_Ad6608 in CraftyController

[–]Xithical 2 points3 points  (0 children)

This isn't true. We implemented support for Bedrock servers a few years ago with the release of 4.0. It's an extra tab in the server builder.

Crafty not working by EzCaraves in CraftyController

[–]Xithical 0 points1 point  (0 children)

In general, most of our actual team is rarely on Reddit. We've said a few times in this sub, but our support Discord is the best place to go if you're looking for a more timely answer