I am the proud owner of my very first server(registered with GoDaddy).
This machine, like most, has an IP. Let's pretend my server IP is 255.255.255.255.
I wish to host multiple servers on this tower: Minecraft, TeamSpeak, Feed the Beast, Garry's Mod, and my website. (Don't worry, I don't get much traffic.)
What I would like is a setup as such:
-------------------------------------------------------
|Service |Subdomain |Actual IP |
-------------------------------------------------------
|Website |digiduncan.com |255.255.255.255:80 |
|Minecraft |mc.digiduncan.com |255.255.255.255:25565|
|FTB |ftb.digiduncan.com |255.255.255.255:9001 |
|TeamSpeak |ts3.digiduncan.com |255.255.255.255:9987 |
|Garrys Mod|gmod.digiduncan.com |255.255.255.255:27015|
-------------------------------------------------------
How would I do this with DNS, or other GoDaddy domain manager options?
BLUF: You can't manipulate port traffic like that through DNS
As far as I know, you can not do this with DNS. DNS is for name to ip mapping. To specify a port like you are trying to do, that happens on the application that are trying to connect to your server. For example, someone connecting to your minecraft server would have to know to connect on port 25565 at that IP address (which can be set on the minecraft client connecting in). If you are going to want to do this through DNS, then you are going to have to have multiple IP addresses (which I'm assuming you are not wanting to do this).
I'm not a boundary device guy but maybe, MAYBE some kind of port redirection on your end with your firewall to your server (network firewall, not host) based on the provided URL. Or have a web service on the server to create a connection back to the client based on URL provide. Just spit balling here. I'm not sure how that would (if it would) work.
Related
I have an express server that uses nginx and monitors the X-Forwarded-For header.
The node server has the following lines of code:
app.set('trust proxy', '127.0.0.1');
app.use(morgan(':remote-addr')); // and other info too
Normally, when users make requests, independent of the client (mobile app, scripts, etc.) the IP displayed is the remote one.
Recently, I have observed that someone tried to hack into my server using python-requests/2.22.0 and the remote IP was not his IP address, it was 192.X.X.X. I tried to reproduce this myself by accessing the server from itself, but the remote address (global server IP address) was displayed.
Can you better explain to me how this works and if this is something I should be worried about?
They never accessed your server through Nginx; check the logs. They sent a local connection header directly to the IP:port hosting your server. This could be damaging if your security policies are not set correctly, it could leak site IPs and potentially allow an attacker to have a free path into your server without response back and no limits.
As we get scarier, the user could initiate a BGP hijack and take over the relay points sending users to your server end-points; this is one to YouTube or google more about.
As we finish off, know most hosting companies allow for private networking and do give somewhat of a firewall to use but most users assume this is secure when it actually is not! These private networks connect you to the hundreds->thousands servers in a rack or zone. So if the attacker bought a server next to yours (which would likely be a bot) they could scan the private networks for some fun-time which is against TOS but the hosts don't check this good enough or secure it.
In your case, it sounds like the server is responding to the entire internet and bots are having a go at it; Try setting your Node.js server up as localhost only, at port 443 or whatever and host that through nginx. That way anytime someone inserts your IP or domain name it is forwarded by nginx to the local resource. Someone couldn't just use the IP + Node.js port and play games. If you do this, a user may still send the header with fake IP but it won't result to IP Leak, or anything bad unless that IP had super powers on your site, which no filter on your site should say 192.168.x.x gets ADMIN mode. You can feel confident.
I have built a d3.js dashboard that ties into a tornado websocket. Everything works perfectly locally. I now would like to have the ability to share the websocket with a few friends, nothing production. Is there a way to do this without a big deployment on Heroku or other similar service? I've googled and can't seem to find an answer. Thanks
Not specific to Tornado. This is more of a networking question.
What you want to do is:
Run your server on your computer.
Connect to the internet.
Note down your public IP address.
Give your IP address to your friends.
Certain things you need to take care of:
Run your server on a higher, non-standard port (e.g. 8000 would be good) because ISPs block traffic to port 80 and other standard ports.
The IP address assigned to you by your ISP will most probably be dynamic. That mean, every time you diconnect and reconnect to the internet, your IP address will change.
Turn off your computer's firewall to let in the traffic at whichever port your server is running.
Finally, you'll need to configure port forwarding on your router. What that means is all the incoming HTTP requests will arrive at your router at your public IP address. But your computer where you'll be running your server will have an internal IP address assigned by your router. So, you'll need to forward incoming requests to your computer's internal IP.
I host a web application on my laptop and I access it using 'localhost:9080/abc.com' and lets assume my IP is '192.168.10.20'
Now, I want my colleague to access this web application from his system 'web browser' by typing in '192.168.10.20:9080/abc.com'
As laptop is owned by 'company' I cannot install (or) use any third party softwares
How can I manage this on RHEL 6?
Assuming you're on the same network (LAN) then a client who connects to 192.168.10.20:9080 should have no problems (assuming the web aplication also listens to requests other than localhost).
If abc.com is just an "alias" you set up in your hosts file then no other person than yourself will be able to use abc.com to connect to 192.168.1.10.20, unless they have the same alias in their hosts file.
If you purchased a domain abc.com and set up it up to redirect to 192.168.10.20 it should work. But usually there are delays associated with updating a DNS so the time it takes for abc.com to be updated can take even a day.
Now if you have your colleagues on a different network (for example they want to connect from their homes when the laptop is connected to the internet at your place) it won't work with a bit of fiddling. Basically, when they try to connect the router gets a request from the client to connect to port 9080, but the router doesn't know what to do with it so nothing happens. You have to set up port forwarding in your routers settings so that all incoming traffic on port 9080 gets sent to 192.168.10.20.
And when they try to connect that way, they can not use the 192.168.10.20 ip adress, because it always refers to a adress on the local network. They have to use your external ip adress (google what is my ip adress).
I am trying to run a server on a different host to my website. How can I set it up so that if people connect to certain ports on my domain that they connect to my server, and so my website still works.
Ports exist on the level of TCP and UDP. There is nothing DNS can do to magically change what happens, at the client or your server, on that level.
For your web site, DNS provides translation of its name to a set of IP addresses. The client's browser will then try to talk to port 80 or 443 on one of those addresses. If you want the other server to use the same name as the web site, it must answer requests on other ports on the same set of IP addresses.
If your server is for a protocol that's new and smart enough to use SRV records, you can use that to actually run the server wherever is convenient but still tell the users to connect to the web server name. Check the documentation for details.
If you can't do that, another possibility is to run a small process on the web server machine that listens to the other server's port(s) and forwards all traffic to wherever the server is actually running. The feasibility and details of doing so depends a whole lot of what server it actually is, so I can't really say any more about that.
Or you could just tell the users to use www.tellusthesoddingname.com for the web site and server.tellusthesoddingname.com for the server and point those names at different IP addresses. Which is by far the simplest and most robust solution.
My Oracle 11.2 database schema has a scheduled job that queries a webpage on my website every few minutes. The database and web servers are two physical Linux machines that sit next to each other and have local IP addresses 192.168.0.11 (database) and 192.168.0.12 (web server). There is a RJ-45 cable cross-connect that directly links the two servers on the same subnet.
If I enter the web address http://xxx.xxx.xxx.xxx/path/to/webpage where xxx.xxx.xxx.xxx is the external IP address, things work fine. Things also work well if I replace xxx.xxx.xxx.xxx with www.mydomain.com.
However, I'm thinking it should be much more efficient if I could re-write xxx.xxx.xxx.xxx as 192.168.0.12 thinking that this would avoid having the request go out on the internet and come back, but rather stay on the same subnet to get to the webpage (thus saving time and resources).
req := UTL_HTTP.BEGIN_REQUEST('http://192.168.0.12/path/to/webpage');
When I try that, I get a 404 error, which makes me think it didn't get to the right webpage.
Can I keep the query on the same subnet by modifying the hosts file or some other way?
My current hosts file already contains an alias for the email server, that is:
192.168.0.12 mail.mydomain.com
If I also include the web address such as
192.168.0.12 mail.mydomain.com www.mydomain.com
would that keep the database on the same subnet when accessing the website? Or will it still leave the subnet to get there? Also, will it confuse things now that I've got two aliases (e.g. one for the database to send emails and one for the database to access webpages)?
I am not sure I would add "192.169.0.12 mail.mydomain.com www.mydomain.com" if that is not the proper IP for the host. That might only make things more confusing.
Assuming that you can ping 192.168.0.12 from the DB server, make sure that your Web Server is listening on the 192.168.0.12 address as well. It could be listening only on the external IP address, in which case, it will return HTTP 404 to every request on the 192.168.0.12 IP/interface.
On Apache, the httpd.conf file would have
listen xxx.xxx.xxx.xxx:80
which would make it listen on the external IP only.
Please note that if the purpose of your HTTP requests is to test the web server availability, you may be better of leaving things as they are. The external test is much more compreheensive than a local one could ever be.