I have setup a small minecraft server and want it to be able to be accessed over the internet. I originally wanted to set up a reverse proxy in order to hide my IP but found out that this is not possible for a minecraft server, which means that my real IP is going to be exposed.
Will my network be vulnerable to DoS attacks if I expose a single port to access the server and use the minecraft's built in whitelist?
This would of course mean that only white-listed accounts can join the server, but I am wondering if this could still pose a threat to the network since all requests would still need to pass through the modem/router. (On which my ISP does not let me manage my own firewall rules).
(I do not intend to publicly advertise the IP and will only share it with friend and family, however I'd rather be safe than sorry.)
Well, yes, if you have a port open you are always vulnerable to DoS! Technically on the Internet you are always vulnerable, even without having a port open... But I guess in your case the risk is minimal, since no one should have an interest to use extensive resources just to DoS some random minecraft server... for hosting games, I have ports open since years and they are even public! but nothing ever happened, because no one cares!
Related
I want to create a Minetest server on my Raspberry Pi 3 in my own network.
I know some discussions have been made (like Any risks in installing my own http server?), but I want to create a Minetest server.
I would like to know
• If it's dangerous to create a server in my own network
• If I can make a protection if it's dangerous.
Thanks
PS : Sorry for the mistakes, I'm French!
I'm going to assume here that you're intending to serve this internally. You certainly wouldn't want to put an external game server on a network that was also shared by your household. The Raspberry PI is assumed to be internal itself without a public IP or any way to be addressed beyond the local network.
Realistically speaking, you can probably assume an internal network is safe enough for inconsequential internal services, if physical and wireless access is adequately controlled. Looks like minetest is a game server, so unless you combine its server with other far more sensitive tasks, it's not like there's any dire consequence to unauthorized access.
But that perspective does seem a little naive, doesn't it? If access were to occur, the raspberry pi could probably be compromised, and from there, the IoT devices in the home, other private services, etc are at risk too. So, perhaps you're just a little too paranoid / experienced / virtuous to leave it at that.
If so, we can probably assume that the connection itself doesn't support much in the way of encryption, but it's likely we can successfully tunnel the connection in any number of ways to add an encryption layer "between" client and server.
The simplest of these is probably ssh. You're already using it to manage your raspberry pi, probably, and if you're not, you might want to (I for one need copy/paste between web and terminal, and I don't want to run gui on pi!). SSH offers a much higher standard of security than most protocols.
Conceptually, you execute an ssh client locally on the game client configured to open a local port on the game client, and forwards packet recieved on that port to a remote port on the ssh server. The remote port need not be accessible on the network directly, only ssh ( the game server would listen on localhost). The ssh tunnel uses strong encryption methods to pass the traffic over the untrusted network ( yours, or perhaps any network for some traffic ).
The process when implemented, would look something like this:
actiate ssh server on pi if not yet done,
obtain ssh client for game client machine. ( Putty for old windows, built in for linux or osx etc, new windows might have better support).
generate ssh keypair on client (each client should do these steps. private keys are ideally never transferred. )
add public key to ssh user on pi and verify that you can login without password
Use SSH tunnel in oyur client to create a local port that tunnels to the remote game server port. https://www.skyverge.com/blog/how-to-set-up-an-ssh-tunnel-with-putty/ looks like a good putty tutorial, https://www.revsys.com/writings/quicktips/ssh-tunnel.html looks decent for unixy environs.
I prefer to take the safe and lazy route, assuming no network is necessarily secure, and weighing the convenience of accessibility against the securiry concerns. Using an ssh tunnel is, once you get used to it, a simple and straightforward way to access services across any untrusted network, by it your own, a public wifi, or the internet at large.
I am trying to understand tor and Im confused about one thing. If one modifies a conventional web browser to use tor, does this give access to .onion websites? Seems that the browser would still not be able to resolve the .onion domain suffix. If true, then what is the purpose of trying to add the tor feature to a conventional web browser? If only for anonymity, then how does this differ from using a VPN?
To modify a conventional browser just involves changing its proxy settings to use Tor as a SOCKS proxy. Tor Browser has a number of other security enhancements and anonymity features, but at the very basic level it can communicate with the Tor controller and the browser proxies everything using SOCKS.
When proxied through Tor SOCKS, it will transparently route .onion addresses over the Tor network to the hidden service destination and back if it is available. When accessing regular internet sites, Tor can resolve the DNS, bypassing your local DNS, and proxy your traffic through an exit relay.
It's different from a VPN in the way it routes your traffic to the destination. With a single VPN alone, your traffic is potentially one hop away from your destination. If the VPN is being monitored or is subverted, it could be possible to see your unencrypted traffic, or at least know what IP addresses you may be communicating with. VPN traffic might be more detectable, require the use of special software, or be more complicated to set up in general.
Since Tor traffic is encrypted with TLS and there are thousands of potential entry points, and roughly 1000 exit relays as of today with an additional random hop in between, your traffic is potentially more difficult to trace back to you without massive or very targeted surveillance.
The Tor Overview and Hidden Services pages can be helpful to read too.
Hope that helps.
I know there needs to be a STUN/ICE/TURN server to find the IP addresses of the peers involved in a WebRTC communication. However, even after IPs are found, how do the peers actually talk to each other independently without having any ports opened?
If you build a website, you usually have to open the ports on your server to have others access your site. What's the magic that is happening in WebRTC that I'm not understanding?
There are several strategies to do this: one possibility is for the client to explicitly open a port via UPnP. I'm not sure if any current WebRTC client does so, but in general networking this is a possibility.
Failing that, the STUN server kicks in. There are several hole punching techniques it can try; read the aforelinked article for the gory details. In short though, a firewall will usually open a port for outgoing traffic (because it needs to receive responses), so by establishing an outgoing connection to a known target and then making note of the port that was opened it is possible to open a port.
Failing even that, a TURN server is necessary. This server is publicly accessible from both peers, even if both peers cannot see each other. The TURN server then will act as a relay between the two. This somewhat negates the point of a P2P protocol, but is necessary in a certain percentage of situations (estimates range around 10%-20%).
The original Question is "what/who creates the sockets?"
The browsers creates the socket and bind them to a local port for you
during the "ICE gathering".
Wether you use any stun/turn server or
not, each candidate generated during the ice gathering has a
corresponding port open.
Those ports are usually open only for 30 mn
after which they are revoked to avoid an attack by someone using old
and/or spoof candidates. These 30mns are not specified in any
specification and are an arbitrary choice by the browser vendor. -
The next question is "how does the remote peer know about which ports are open".
through the ICE mechanism, which for each media will generate potential candidates and send them to the remote peer through your preferred signaling channel.
ICE candidates (which are one line of SDP, really) have a "type". if this type is HOST, then your candidate is a local candidate generated without the use of any stun or turn server. is the type is SRFLX, then you have used a STUN server to add the mapping between your local IP:port and your public IP:port. if your type is RELAY, same thing with a TURN server.
of course, using the local IP:port HOST candidate will fail unless the remote peer is on the same local network.
From the browser and local system point of view, the socket is open on the local IP:PORT anyway. Hence, opening the sockets and finding out on which port a remote peer should connect to connect to the socket are separate problems handled separately.
The Final question is: "can it really work without a STUN server"
Most probably no, unless you are on the same sub network.
Stats shows (http://webrtcstats.com) that even with a STUN server, you still fail in 8% of the case, for the general public. It's much more in enterprise, where you'd better have advanced turn (supporting tunneling through TCP/80 and TLS/443) and even support for HTTP proxy's CONNECT method.
We meet a testing scenario which needs to tamper with source IP address of a Http request to simulate clients coming from different countries. Do you know any tool help on this?
Last but not least, our web site is built with ASP.NET.
Thanks.
In a test environment it usually isn't difficult. First read this SO question about virtual network interfaces.
If the server and client are on the same machine, all you have to do is figure out how to get your client software to bind to your virtual interface.
wget for instance has the --bind-address option to specify which local address to bind to. Web browsers are a bit more difficult to do this with; you may need to just run it in a VM.
If your server and client are on the same LAN, you just need to configure your router with some static routes to your client machine. In this case you probably don't need a virtual network interface, just set a static IP for your client machine; as long as the gateway is set up correctly it should be able to send packets to the server, and as long as the route is set up correctly the replies should find their way back to the client.
If the client and server are separated by an internet, it's rather more difficult. One option is to set up a network tunnel endpoint on the server and tunnel it to the client machine, which "knows" that it has the virtual network interface.
As noted in answers to the ServerFault question "Are IP addresses trivial to forge", you cannot easily forge source addresses in a protocol that required two way communication (e.g. TCP). Note that this "two way communication" is required at the packet level. You cannot just say "no problem, I want to send requests and ignore HTTP responses." To establish a TCP session, you need to receive data. Your best bet is to use a proxy server.
I am unsure if the IP standard allows for this, but if you are working in a Lab environment, where you don't need internet connectivity during the test, I can see it working under following circumstances:
Basically, I would set the server's network interface to use netmask 0.0.0.0 and flush the rest of the routing table.
Then you could configure a client machine to take on any IP address as long as you use netmask 0.0.0.0. And two-way communication should be possible.
Server[1.2.3.4/0] <---> Client[x.x.x.x/0]
But please bear with me. I haven't tested this, so I could be wrong :-)
If you have access to your infrastructure, you can add an interface off the router and then place a static route on the router to that network.
Server-----Router----Internet
/
Test_PC----/
Alternatively you can look into PBR (Policy Based Routing) and on the routers you can flag source packets and change the source on the fly, so your server will think they are coming from where you'd like them to come from.
Server-------------Router_with_PBR-------------Internet----- PC
SCR:4.2.2.2 Change SCR:6.6.6.6 to 4.2.2.2 6.6.6.6
But you have to ask yourself why do you want to see when packets come from different countries. Some countries have massive proxy servers that filter access ( "Great Firewall of China"), so the above tests will not prove much.
Your best bet then is using proxy servers or if your looking for a long term solution then setup a server (virtual is great for this) and use RDP for testing. I'm sure you can rent a virtual server somewhere for a month or two.
That's not possible. Because when you forge the ip address, the response is never going to come back, which is required for http.
The best way is to use proxies. See also this question on serverfault.
If you change your source IP address, that means no traffic from your web server will be able to reach back to the client.
You might be able to use some kind of proxy and/or address translation filter to do the remapping while still allowing two-way communication.
In short: How to reliably discover a server running somewhere on a (presumably multi-segmented) local area network with zero client configuration
My client application has to locate the server application without knowing the server IP address. It has to work on a local LAN that may be split into segments with hubs or other switching devices.
I already have a working solution, but it is a bit cumbersome to get it working on multi-segment networks. It works as follows:
When the client starts up, it sends UDP broadcasts on its own network segment. If the server is running on the same segment, it works without any issues - the server responds with the appropriate messages.
If the server and client are running on networks separated by a hub / switch that won't forward UDP (the most likely case), then I have a server instance running on each segment, and they forward client requests to each other via TCP - but I need to configure this for the server instances (simple, but still a pain for tech support.) This is the main problem that I need to address. There are sites where we have hundreds of clients running on 5 or 6 separate segments.
The problems I'm facing:
1. Although my application installer enables the appropriate ports on the firewall, sometimes I come across situations where this doesn't seem to happen correctly.
2. Having to run multiple server instances (and therefore configure and maintain them) on hub/switched networks that won't forward UDP
Finally I need a solution that will work without maintenance on a minimal Windows network (XP / 2000 / Vista) that probably doesn't have Active Directory or other lookup services configured.
I don't want to tag on any runtime stuff for this - should be able to do it with plain VC++ or Delphi.
What approaches do commercial apps usually take? I know that SQL Server uses a combination of broadcast and NetBEUI calls (I may be wrong about this).
Thanks in advance.
You have a few terminology issues:
Where you say "network segment" you appear to mean "IP subnet". Devices on the same network segment can see the same IP broadcasts.
Where you say "hub/switch" you appear mean "IP router".
Where you say "won't forward UDP", the problem is actually "won't forward IP broadcasts".
Once we get past that, you have a few options:
Your servers could register themselves under a well-known name in DNS, if you have a DNS server that allows dynamic DNS updates. You should probably use a SRV record as specified in RFC2782. The clients then do a DNS lookup to find the server(s).
You could statically assign your server(s) well-known names in the organisation's DNS, perhaps with a SRV record as with the previous option.
Your servers could join an IP multicast group, if your routers support IP multicast. The clients then send their initial discovery request as a UDP packet to the (pre-ordained) multicast address.
If you have domain server, I would go with small service on it. You can connect with other services to it and use it as distribution point.
Why domain server? It is relatively easy to find it's name (DsGetDcName).
Other choices would include DHCP server, DNS server or something of that kind that needs to be filled by maintenance staff anyhow.