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.
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.
For example, I've a server hosted at my home with 2 NICs for redundancy obviously.
NIC1 has been assigned with the public IP 103.204.82.22 from ISP1
NIC2 has been assigned with the public IP 144.110.12.64 from ISP2
I can access the server with both IP as usual.
Now, I have a domain acme.com. I've created a subdomain server.acme.com. I want to point server.acme.com to both the IPs so that in case one ISP fails to provide connectivity my server still remains online with the other one.
I've already tried with A and CNAME records. But it isn't working. It's working with A record if I use only one IP for the subdomain.
Can anyone tell me what and how can I point both the IPs to the single subdomain?
Thanks in advance
What you are describing is called DNS round robin, but that won't give you your expected outcome.
Anything you do with DNS if one ISP connection is down, traffic will still go there.
You may have your terminology mixed up a little to start with.
in this case, I suspect you really mean that server.acme.com is a host record, rather than a subdomain. (A subdomain would mean that the server address would be at servername.server.acme.com)
If you create an A record, and put both IP addresses in, and keep the TTL (time to live) short, then when a client wants to contact your machine it will randomly pick one of the addresses. If that address is unavailable, it will move on to the next. If that address stops working, it will keep trying it for the 'TTL' time.
Presuming that the IP addresses don't change, which would be a different problem altogether, then this provide basic load balancing and failover to both connections.
Amazon provide a more advanced type of DNS, that will actively monitor your connections and only provide responses that are live. - https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html
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.
Reading a lot about servers, load balancing and similar topics, a question came to mind.
DNS servers are servers which gives you the IP for a given domain name. Is there a "dictator" knowing all the valid DNS servers in the world? If I want to make a DNS server, and someone requests a website it doesn't have. How would it know which other DNS to redirect the request to? What if I tell facebook.com to have a spoof IP, and everyone getting the IP from my DNS server would be communicating with a spoof facebook server? Obviously, this isn't how it works (at least not at a big degree), because then someone would have done it already to attack hundreds of people.
When one registers a domain, one has to specify the name server for that domain. What happens during this process? Is a request sent to this DNS server to notify it there is a new domain to save in the database? If so, how can anyone own the top domains like .com? And why cannot I for example make my own top domain name if I can make my own DNS server?
After looking at nginx as a load balancing system, I'm starting to wonder a bit. Is it so that a request to http://www.google.com/ works like this? The computer asks a DNS server for the IP address for google.com, and then requests it? This will only be one IP, and all requests to Google ends up at this one server? And then this IP will be connected to a nginx server, or a more basic hardware unit to route the request internally to other servers? So all requests go to one server before it redirects the request to a data center?
After looking up google.com, it says the name servers are ns1.google.com etc.. But what is the point of them, if you need a different name server to get to ns1.google.com in the first place?
Obviously what I've written doesn't make sense, because if it were true, the web as a whole would be unusable because of people exploiting the possibilities for malicious causes. And I can't imagine how ONE server could handle ALL the requests thrown at google.com.
I've tried searching Google, but all I get is theoretical explanations that led me to where I am now. It would have been great if someone would point me to some articles that explain this thoroughly, and hopefully a lot of other people will find this question useful.
Anyone can run a DNS server, but the challenge is getting someone to use it. Normally the DNS server IP is provided as a DHCP option or is statically assigned. If you can get someone to use your server, you can return any IP for any hostname, including creating new top-level domains (subject to any filtering at the client, of course. Web browsers might have difficulty with a new TLD, for example). Note that with DNSSEC, this will eventually change, as the name record will be digitally signed and your server won't be able to fake the signature exactly.
DNS servers operate in a tree. When one server receives a request for a domain it does not control, it forwards the request on to another DNS server. The other DNS server may be the one which returns the IP (this is called the authoritative server), or it may return a NS record which points to another server which then must be queried. The DNS root servers provide for resolving TLDs.
A DNS server does not need to always return the same IP for a given name. It may choose to return a different IP based on region, client IP, or even per-request. This is the most typical way to load balance. Multiple DNS servers can also load balance the DNS requests by using anycast routing, where many servers share the same public IP and traffic is routed to them randomly by publishing multiple routes for the same IP.
I have a couple EC2 instances behind an Elastic Load Balancer. These instances serve HTTP requests for a single web site. I recently started looking at the HOST header of the traffic, because I am planning to split my app into virtual hosts.
With some regularity (dozens of times a day), I log a request for a host name that is totally unrelated to my servers. As a couple examples, today I saw requests with the host names ad.adserverplus.com and r1---sn-upfn-hp5e.c.youtube.com. I looked these up and the IP addresses are not the same as any of my servers, nor of the ELB, so I am trying to develop a theory as to how this happens.
I realize that someone could be spoofing the host header, but it happens often enough that I am pretty sure this is not what is going on. My other idea is that somehow there is stale DNS data that just happens to resolve one of those hosts to my IP address, but again this seems like it could happen once in a great while but not regularly. What are some other possibilities, and how might I verify / discredit them?
EDIT
I looked at some of the unexpected host names today, and it seems that they actually do resolve to an IP that is one of the possible IPs that my domain apex resolves to. I use Route 53 for DNS, and I have the zone apex pointed to the ELB, so when I query the IP address for my domain, I get different answers depending on when I ask. So this makes me very curious, how do these IP addresses get assigned to me and how does EC2 make sure they are not co-opting an IP address that someone else is already using.
There are any number of reasons for this. First you should understand that the public host name for your EC2 instances and load balancers have likely been used before. If you have an elastic IP associated with your load balancer, it has also probably been used before.
As such you can get traffic to your servers that is intended for a previous tenant of that hostname of IP address that you are currently using.
One thing you can do is to configure your web servers to reject traffic (respond with 403) to traffic that is not arriving with the proper hostname specified or that comes from a specific external host.
Your IP or your ELBs IP may have at one point in time been an open proxy. meaning that someone is hoping that you would forward the requests on to their intended destination.
but in general open port 80 to the internet and all kinds of bots and zombies will visit you with a pretty constant flow of dodgy requests. I would imagine though that the \ec2 IP ranges would be a particularly juicy range to search for poorly patched websites to exploit.