With some games and applications, it may be necessary to open one or more ports or setup port forwarding on your home router. Below are the steps required with most routers and additional help and suggestions with troubleshooting issues that may be encountered.
Ports are often closed on a router to help prevent unauthorized access to your home network. Opening any additional ports on your router may decrease the overall security of your network.
NoteIf you want to open ports to give access to a game or an application like BitTorrent, make sure it is absolutely necessary. In some situations, it may be a firewall on your computer or router that is blocking access. Try temporarily disabling your firewall to make sure this is not the cause of your problems.
- To use port forwarding, first determine the local IP address of the computer.
- Open your router configuration.
- Once in the router configuration, locate the port forwarding settings, often in a section such as Applications & Gaming or Port forwarding. If you are having trouble finding these settings, we suggest trying the Port forward site for exact steps on your router or refer to your router's documentation.
- Once at the port forwarding screen, you will see a screen similar to one of the example picture below.
Single port forwarding
Referring to the following picture as an example, with single port forwarding, you have different fields that need to be completed.
First, the Application Name is the name given to describe what the ports are that you are opening. In our example below, you can see this router has drop-down menus and empty boxes. If you are opening a common port such as FTP, selecting that option enables that port. However, in most situations, you need to type the name of the application. For example, you would type in the name of the game.
Next is the Externet Port and Internet Port. Enter the port you want to open in both of these fields. For example, if you were opening port 88, you would enter 88 in both boxes.
Next is the Protocol, which is often able to be either TCP, UDP, or both. If you are uncertain of the exact protocol needed, use both. If you do not have a Both option, create two open ports for both TCP and UDP.
Next is the To IP address, which is the IP address of the computer or networking device this port is being forwarded to on the network.
Finally, once all these values have been configured, check the Enabled box and click the Save Changes button.
Port range forwarding
If your application or game requires a range of ports, such as 6112-6119, your router should have a Port Range forwarding section like the one shown below. In this section, you would follow the same steps as those mentioned above, however, instead of entering an individual port, you would enter the starting and ending port number. For example, if you were given instructions to open port 6112-6119, you would enter 6112 as your starting port and 6119 as your ending port.
DMZ
Finally, if after enabling port forwarding you are still encountering issues with another computer or application seeing your computer, it may be necessary to enable DMZ. Often this setting is in the same area of the router configuration as discussed above and can be changed from disabled to enabled.
Testing if an outside network can see the new port
There are several services that can test if your new opened port can be seen. We suggest trying Canyouseeme and the port checker tool from Portforward.
Additional information
- See the port and router definitions for further information and related links.
I just wrote out a lengthy, detailed story about what is going on, and then when I went to post, I had apparently been logged out and it said I didn't have permission. So I'm going to try to summarize. I greatly appreciate any help someone can shine on this.
I am getting bursts (about 20-30) of pings from an outside address ( 3.0.1.128 ) with a destination of 28.164.4.176. The source appears to belong to General Electric in Fairfield, CT. The destination appears to belong to the Dept. of Defense Network Information Center in Columbus, OH. It looks like for some reason, my and my fiance's iPhones (6, up to date on software, no jailbreak) are randomly being assigned that 3.0.1.128 address and that is when the pings come, and we occasionally lose connection. I have a Netgear 3000-100NAS modem/router. I have exchanged the gateway, to get a new MAC address, to force my ISP to issue a new public IP. The problem continued after this. The phone that gets the IP seems completely random. I am also being port scanned by Comcast's DNS. These pings are occasionally knocking us offline, and then it reconnects. The phone that picks up the address is seemingly random, but never both at the same time. Then after a few minutes they pick a local address from the DHCP.
On our network we have 2 laptops, a xbox one, a roku, and then our two smartphones. I basically just left out all of the story telling and dealing with customer service, etc. If there is anymore information I can provide, I will be glad to. I really hope someone can help.
As we all know, the DNS exists because it’s impossible for humans to remember IP addresses for sites, but easy to remember alphanumeric names. The DNS system was created when the Internet was a friendly place — leading to quite a few issues.
Figure 1 shows how name resolution fundamentally works. When an application (like a browser) wants to connect to a destination service, it queries the DNS server, asking for the IP address. This query is sent over UDP port 53 as a single request and receives a single-packet reply from the server. (Note that since UDP data space is limited to 512 bytes, the protocol stack automatically uses the TCP protocol for queries and replies.) When the client receives a reply, it updates its local cache with the received entry, speeding up subsequent queries to the same domain. Entries in local cache are automatically purged after their TTL (Time to Live) expires.
The DNS uses record types like A, CNAME, SOA, MX, etc. While explaining these is beyond the scope of this article, it is important for administrators to know the usage of each, and before implementing them, they should be evaluated from the security standpoint. Before we learn about DNS-based attacks, we need to know about two types of queries — iterative and recursive.
Tcp Ip Ports List
- An iterative DNS query: When a client queries a DNS server, asking if it has the answer for a given domain name, the DNS server may or may not have the answer ready. If the DNS server doesn’t have an answer, instead of shutting the request down, it sends the name of an upstream DNS server that might have the answer. This is usually called a DNS referral. The client sends the query to the next (referred) server; if that one too doesn’t have an answer, it sends a referral to yet another upstream server. This process continues till either the client gets an IP address or gets a “query failed” error message.
- The recursive DNS query: In this case, the query begins by a client host requesting a name resolution to its immediate DNS server. If the DNS server does not have the answer, it is supposed to do the job of talking to upstream servers, instead of merely providing their referral names. Again, if the upstream server does not have an answer, it needs to take on the responsibility further. This continues till either the root domain server is reached, which must have the answer, or if the queried name itself does not exist, in which case an error message percolates down the chain to the client. Unlike the iterative method, a recursive query proves to be more aggressive in getting query results.
Iterative queries are usually made by DNS servers while recursive queries are made by clients, which helps to reduce the burden of referral searches. From the security perspective, it is important to know the basics of DNS, such as, there can be multiple DNS servers in an organisation replicating their zone records to each other in order to maintain name resolution consistency.
DNS data can be updated dynamically without needing any service to be restarted, and when a change is made on the master server, it triggers replication to partner servers automatically. The actual time required for replication is defined by the TTL of each record. In case of geographically dispersed DNS servers, this time period can be as long as a day, since all servers in the chain maintain their own cache to speed up replication.
DNS security attacks
It has been observed that systems administrators spend a lot of time designing security around applications, servers and other infrastructure components, but unfortunately tend to forget hardening DNS servers. Please refer to Figure 2, which shows possible breach points where the DNS can be vulnerable to attacks. By design, the DNS heavily relies on UDP, does not contain security by itself, and does not have foolproof built-in authentication — which makes it more susceptible to hacking than other network-based services. Let’s look at a few very common DNS attacks.
DNS cache poisoning
This attack lets name resolution to be tweaked in two ways. In one method, the hacker installs a rootkit or a virus, which is intended to take control of the local DNS cache of the client. Once done, entries in the local DNS are altered to point to a different IP address.
For example, if a browser tries to access http://www.cnn.com/
, instead of getting the CNN IP address, it gets an IP set by the hackers’ script, which is usually in the hackers’ own Web farm, and hosts viruses or shows some derogatory information.
In a different and more dangerous approach, the hacker attacks a DNS server and alters its local cache — so all servers using that DNS server for resolution end up at a wrong IP address, causing a system-wide failure, apart from information loss or theft.
In rare cases, hackers can access a root DNS server, which holds the base entries that form the root domain, such as .com
, .net
or any country-specific name system. Hackers then modify entries on that server, which triggers automatic replication, and can cause serious global outages for multiple businesses and websites. Though such situations are rare, they have occurred — and that too, very recently, involving a famous social community chatting website.
DNS hijacking
What Is A Router Port
This attack is also commonly used to bend the DNS system. Here, the client DNS cache on a client is not altered, but instead the client’s DNS settings are changed to point to the hackers’ own DNS server. Usually the purpose is not to steal data, but to gather statistical data from the client computer. All name resolution requests going to the hacker are resolved to the correct addresses, but the hacker learns of the typical sites visited by the client.
This information can further be used by online advertisers to target that client with Web-visit-specific advertisements. Some ill-behaved e-thieves also redirect users to their own websites, or search engines, either to gain money from advertisements, or simply to steal data and use it for social engineering. While it is inappropriate to use this feature for any personal gain, it is being used by many well-known websites and ISPs to collect user browsing statistics.
DNS spoofing
This refers to merely a man-in-the-middle type of attack in which the hacker gains access to the network the DNS server is on, and performs ARP cache poisoning and spoofing on that network. Once MAC-level control is achieved, the hacker then fetches the IP address of the DNS server, and starts sniffing and spoofing requests meant for the real DNS server.
The hacker’s machine resolves all DNS queries, completely bypassing the real DNS server. This has serious consequences, because all machines on that network can be completely unaware of this, and end up sending DNS traffic to the hacker’s machine.
There is an alternate method called DNS ID spoofing. Each DNS request and response carries a unique identifier, to differentiate between various simultaneously generated requests to a DNS server. This unique ID is usually a combination of the MAC address and the date/time stamp, and is created by the protocol stack automatically.
A hacker uses a sniffer to look at one or more DNS requests and responds with their respective unique number, but with a false IP address. This results in the client’s local cache being updated to this fabricated address. Further damage can be caused by hosting a virus on the machine at that IP address.
DNS rebinding
Also called DNS pinning, this is an advanced type of attack. In this method, the hacker first registers his own domain name and sets the TTL value of that domain at a lower value, which prevents that domain name from being cached.
DNS denial of service
As we learnt in the very first article of this series, bombarding the UDF port 53 or TCP port 53 with DNS queries can cause a DoS attack. Another method is to perform a ping of death or a TCP SYN flood attack. The idea behind this is to overwhelm server resources (CPU and memory) to stop it responding to queries. Though DNS servers are protected by firewalls, if care is not taken to block DNS UDP ports from non-trusted networks, it exposes the name resolution system to this attack.
DNS amplification
Amplification means to provide the DNS server with a task heavier than it is capable of handling. There are multiple ways to stress the server and eventually make it non-functional. In one method of amplification, a Trojan is written to poison and populate the local cache of multiple client hosts. This forces all infected clients to send their name requests to a particular name server, which is being targeted by the hackers.
Each server can only respond to a certain number of queries (based on CPU speed and configuration) and eventually starts queuing up requests. As more and more clients get infected, the increasing number of queries ultimately makes the server give up.
In another type of attack, a hacker poisons the DNS server’s cache; instead of changing the associated IP address of an A or CNAME record, a change is made to the domain name. To make it worse, the domain name is made to contain a few hundreds or thousands of characters. This starts the replication process, and hence the download of multiple kilobytes of data from the main name server to its replicating partners, and eventually to clients.
Upon expiration of the TTL, the replication process initiates again, and results in the breakdown of one or more DNS servers in the chain. This trick actually simulates a distributed denial of service attack, and hence is very dangerous and hard to control.
Protecting FOSS systems
In the FOSS world, the DNS service is a well-known implementation across the globe, simply because it proves to be the fastest available name resolution mechanism. A widely used and famous example is the Bind utility/service. However, since most DNS attacks exploit the basic design lacunae, it becomes a tougher task to protect FOSS-based name resolution systems.
The very first step to protect a FOSS DNS server is to lock it down at the network level. Besides the server management ports, only the DNS query ports should be allowed and the rest must be blocked on the firewall as well as in OS-based port filtering.
The second important step is to not install any other software on a DNS server, other than the name server service itself. This precaution must be followed especially in the case of an externally facing corporate root name server that holds all internal name spaces, and resolves external name queries for the local area network.
It is often found that vulnerability in another program on the name server leaves a back door open, resulting in intrusion into the name service. While most critical infrastructures implement a firewall, a UTM device and powerful anti-virus or anti-Trojan software, it becomes imperative to have an intrusion detection system (IDS) in place. An IDS is capable of filtering out sneaky Layer 2 and Layer 3 attacks such as ARP spoofing, IP spoofing, packet sniffing, etc.
Besides the above crucial precautions, there are a few advanced methods that can be followed too. As we learnt earlier, each query carries its own unique identifier and is marked in the UDP packet. Unfortunately, due to the design of DNS stacks based on RFC standards, these identifiers are easily predictable, and hence randomising those can be a good idea to prevent spoofing attacks. Similarly, the UDP port on which the name server responds is predictable too, and can be randomised.
There are open source tools available on the Internet for just this purpose; however, please note that it adds a bit of a delay in query resolution. A fairly recent and popular protection technique is DNSSEC (DNS Security Extensions). It protects clients and systems from cache poisoning attacks by digitally signing records using public key encryption. While working in a similar fashion to SSL, the querying and answering hosts need to establish a digital trust between each other; once it is achieved, name resolution takes place.
Once the process is completed, the session is torn down, thus protecting the security at either ends. DNSSEC is being implemented by most ISPs in the world.
DNS invasion is a common phenomenon in the IT security world. It involves exploiting DNS design loopholes to gain access to the IT infrastructure or to lure the client computers to a phishing farm. FOSS is also susceptible to such attacks and hence network administrators must understand the techniques to protect their infrastructure from information loss or theft.
scenario of wifi : i'm using wifi in hostel which having cyberoam firewall and all the computer which uses that access point. that access point have following configuration
here, when i try to open a website the cyberoam firewall redirects the page to a login page (with correct login information, we can browse internet else not), and also website access and bandwidth limitations.
once i've heard about pd-proxy which finds open port and tunnels through a port ( usually udp 53). using pd-proxy with UDP 53 port, i can browse internet without login, even bandwidth limit is bypassed !!!
and another software called openvpn with connecting openvpn server through udp port 53 i can browse internet without even login into the cyberoam.
both of softwares uses port 53, specially openvpn with port 53, now i've a VPS server in which i can install openvpn server and connect through the VPS server to browse internet.
i know why that is happening because with pinging on some website(eb. google.com) it returns it's ip address that means it allows dns queries without login.
but the problem is there is already DNS service is running on the VPS server on port 53. and i can only use 53 port to bypass the limitations as i think. and i can not run openvpn service on my VPS server on port 53.
so how to scan the wifi for vulnerable ports like 53 so that i can figure out the magic port and start a openvpn service on VPS on the same port. ( i want to scan similar vulnerable ports like 53 on cyberoam in which the traffic can be tunneled, not want to scan services running on ports).
improvement of the question with retags and edits are always welcomed...
Another Question
i'ave made simple client server application in which a external computer acts as server running on UDP port 53 and client running inside the wifi; will connnect to that out side server that is running on UDP port 53. problem is it can't connect that server application.what should be the reason, why client inside wifi can't connect outside server running on UDP port 53 ?
NOTE : all these are for Educational purpose only, i'm curious about network related knowledge.....
2 Answers
To identify the magic port, you can use nmap while inside the wifi network, and scan the IP address of your VPS for all UDP and TCP ports:
The idea here is that the firewall at the wifi end is blocking packets leaving the local network, but any that get through, must be via open ports. So on the VPS side, you run
You will need to work out the public address by going to http://whatismyip.com
We are not interested in the results that nmap comes back with, we want to see what tcpdump sees - any packet that makes it to the VPS will have passed through the firewall, so the destination port of the packet will tell us which ports are open:
The above fragment shows that a packet arrived on the ssh port, which is 22, which must be permitted through the firewall.
Dns 53 Tcp Or Udp
Note that while you are able to do DNS queries, it does not follow that port 53 is open to the internet. The usual case is that you are permitted contact to controlled DNS servers, and it is those that can forward DNS requests out to the internet - much like in a domestic setting you often set your router to be the DNS server for the network, and it is the router that resolves queries.
If it is the case that port 53 is open only to specific DNS server, then you can get around it using an IP over DNS tunnel. If you have a VPS running a DNS server and you have a domain name you can can control, you could use iodine which allows you to tunnel IP over DNS queries, and so removes the need for OpenVPN (though running OpenVPN inside the tunnel will ensure your packets are protected. You could also do the same with ssh).