I'm running a game server on my Windows Server 2008 VPS. It uses ports 443 and 444.
Recently there are some suspicious activity from a user. I always have access to the users IP address. How to find out what requests are sent to these ports from that IP?
If you want to see packets that came in and goes out from you server you can install wireshark and capture all packets or filter them by specific ports.
Related
I read on Ports WIKI page that "Ports are logical constructs which identifies a service or process", what service or process means here? It means protocol like HTTP, FTP etc. or software applications which are configured to listen on that port?
When it is said that application is listening on so and so... then does it listen for request to an IP address or a port, or listens on a combination of port and IP address? Application listen for a specific IP address and one or more ports are bound to it OR it listens for a combination of IP and port?
For example, I can have application configured for 7001 for HTTP requests and 7002 for HTTPS requests. So, would be listening on 7001 or what?
Applications/services such as a HTTP web server or an FTP server are assigned a port to use/listen on, usually in the config of the application. and they often use a standard port. HTTP for example usually uses port 80.
If an app/service is listening it listens to a port and has no relation to a specific IP address. This is because the IP address it is listening on is the IP address of the computer that the app/service it is running on.
I need to know the ip addresses visiting my server (Windows Server 2003). Scenario - The clients are accessing a particular tool
You can use Wireshark to record all the details about incoming and outgoing connection (IP, ports, packages, etc)
You can use Wireshark or Microsoft Network Monitor (NetMon).
If your server is behind a NAT with Port Forwarding, you should use NAT logs to see who accessed your server.
In IIS, there is a way to log the client IP address, I found this: Log.
You cna also obtain the IP address in your server application, log it, and later analyze it with any log analysis tool.
I'm setting up 4 servers that each have RESTful APIs that go over HTTPS. Because we're in the early stages of a startup, I'm going to host these in my closet.
I have business-class Comcast service, so I can get a static IP address or a series of them. The IP addresses are $10/ea per month, so I can save about $30 if I get just one. I realize this sounds like I'm being super cheap, but we're pinching pennies until we get some customers.
We will probably use one server as a "tools" server that will allow us to reach the other servers via SSH; the other 3 servers will need to have HTTPS open to the internet on the LAN.
I'm considering getting one static IP address, and then using my router to forward HTTPS traffic to the various servers. The port forwarding would look something like:
WAN Port LAN Port Server
22 22 Tools
1443 443 Server 1 (API via SSL)
2443 443 Server 2 (API via SSL)
3443 443 Server 3 (API via SSL)
I would then set up A NAME records in my DNS that would be:
tools.mydomain.com -> <static IP address>:22
server1.mydomain.com -> <static IP address>:1443
server2.mydomain.com -> <static IP address>:2443
server3.mydomain.com -> <static IP address>:3443
Is this a reasonable approach? Will it work?
You cannot direct traffic to a specific TCP port with DNS records. You can only point at an IP-address. The client by default uses tcp port 80 for HTTP and port 443 for HTTPS (unless you explicitly name the port to use in the URL).
Furthermore you cannot have multiple HTTPS-based hosts using the same IP address unless they also use the same SSL certificate. That is because the SSL handshake takes place before the client reveals to the server which hostname it was trying to reach, so the server can only give out an SSL certificate based on the IP address (and port) that was connected to.
In this particular instance, if you have four servers that actually have the same domain, you can get a wildcard SSL certificate (i.e. it covers *.mydomain.com) and then you can actually get away with one single public IP address for all four servers. Just point all DNS records to the same IP address and then you have the server give out your wildcard certificate which is valid regardless of which hostname the client is using. After the SSL handshake is thus completed, the server can look at the Host: -header in the client request to determine which server the request was actually intended for, i.e. you have one server acting as the HTTPS-endpoint where all HTTPS-requests are received and then internally forwarding to unencrypted request to the correct server (or handle all servernames virtually by one physical server).
If you are using Apache HTTP server I suggest you read about name-based virtual hosts and proxy forwarding:
http://httpd.apache.org/docs/current/vhosts/name-based.html
http://httpd.apache.org/docs/current/rewrite/vhosts.html
http://httpd.apache.org/docs/current/rewrite/proxy.html
Suppose I have a VPS with private networking setup such that the only ports that are open are the port for SSHing into the server and the port that connects the server to other servers on the private network. Can this same server still send requests through the internet and receive back responses? If so, through what 'channel' are the requests/responses being sent/received?
It depends on what the outbound firewall settings are on the server. If the firewall allows all outbound connections then you can connect out to any server on any protocol.
However, depending on the hosting provider, they may limit the ports which you can use for outbound connections. Most likely (but not guaranteed) you'll be able to use HTTP (80) and HTTPS (443). It is quite possible that SSH (22) would be open as well. Those three should cover most, if not all, of the needs to would have.
Imagine we have a hosting containing:
a search engine running on port 5678 (it's required this port it's open in order to work).
nginx running on port 80.
When a user connects to our website and search something on it, he is only connecting through port 80, but never through 5678. We can check this running "netstat -an".
So my question is: If the client it's never connecting directly with the search engine's port, why we need to keep it open?
Normally client requests are coming to your web server (port 80 or 443), and your web server (your php,or your java code) has a logic to connect to your search engine and send back the result to the client via port 80/443 (local socket connection, if web server and search server running on the same server). so clients need not to connect directly to your search engine port (5678). (from external networks). may be your web server internal interface and search engines internal interface connect locally via local s socket connection.
I'm not sure how you run your web server and search engine, is it two different servers or nginx act as a load balancer and send the client request to your multiple search servers. i think your search engine port use internally to communicate with your web server hosted software. or may be you run both nginx and search server on the same server.
other guess is your firewall or router forwarding port 80 request to your search server port 5678 (port forwarding).
try this on your search server
netstat -pant
this will give your all connection details, like local address,foreign address,state, and PID/Program name
Hope that helps
You can connect to a webserver using a different port. Port 80 is the default for web servers. (port 443 for secure, https, connections) so it's not normally specified since it's 'understood'
But you can, actually, specify a different port to connect to. In your example, a user would specify which port they want to connect to in the URL
http://www.example.com:5678
The same reason why some services live on other ports, like 22, 3000, 3306, 8080, 9000, you might not access those ports directly but maybe some other apps/services/protocols connect to it internally, or could even be not on the same server, like if you have separate app/db/mail servers, they would contact each others by ports.