47

How are they (ISP) achieving this, Are they really stealing and MITM ing the traffic of 8.8.8.8? They probably simply redirect all packets with destination port 53 (i.e. DNS) to their own servers and answer the query themselves. This is not that hard to do. How can I get around this without VPN? A properly configured VPN (i.e. no DNS leaks) can get ...


30

Short answer: No, third parties can't register a subdomain without authorization from the owner of the domain. DNS is a hierarchical system, ordered from right to left in the hostname. Whoever has a given domain name registered controls the authoritative name servers for that domain. This means that all queries (that aren't answered from cache) for that ...


28

Welcome to Security! The case of educational/government intitutions is a particular case of subdomaining. Basically ICANN, who rules the Internet top names, delegated maangement of the .au TLD to Australian government (to make it simply simple). But since .edu and .gov (et similia) are owned by US for historical reasons, Australia, like some other countries, ...


24

Assume you managed to poison the DNS cache for securesite.com with an IP that you control. Now, when the client visits https://securesite.com, it will resolve to your IP address. As part of the SSL handshake process, your server will need to send a valid certificate for securesite.com which contains the public key. At this point, you have 2 options. 1) ...


23

Something in your environment has definitely been compromised. It seems more likely that your router has been compromised. You haven't provided much information, so I'm going to make some basic assumptions: You're at home You are behind a commercial router, provided by your ISP You haven't done anything to secure your router Your linux desktop is a DHCP ...


20

This won't work for many websites. Many websites use virtual hosts where they host websites for multiple domains from a single webserver. In this case, the only way they know what site you're coming from is by the hostname your browser sends in the Host header of the HTTP request. The way to do this would be to specifically add these entries into your /etc/...


20

The first and main thing is to ensure that the firewall on your host is configured to properly drop incoming packets with source or destination address set to 127.0.0.1. Under normal circumstances, there should be no packet coming from the network and showing such addresses. However an attacker may attempt to forge such packets in order to reach your local ...


20

unfortunately they are not doing so! They are doing so, and your typescript shows it happening, with nslookup querying that IP address and getting answers from it. Your confusion stems in part from a misconception of what 8.8.8.8 is. It is an anycast IP address. Traffic sent to it is routed to the network interfaces of multiple machines around the world, ...


19

The DNS registrars only care about the registration of the primary domain, i.e. example.com. They don't care about any sub-domains like www.example.com or www.math.example.com and similar. These are in full control of the organisation which owns the primary domain, which also might decide to delegate control over these domains or some of these domains to ...


15

Despite what Wikipedia may say, they are not the same. Roughly speaking, DNS cache poisoning is one way to do DNS spoofing, but there are other ways to do it, too. DNS spoofing refers to the broad category of attacks that spoof DNS records. It is a category of attacks (an end goal of the attack, rather than a particular attack mechanism). There are many ...


13

Since DNS usually runs over UDP, response packets can be readily spoofed. UDP packets are identified by the combination of source and destination IP address and source and destination port numbers. The classic DNS poisoning attack is to send a DNS server a query which you think will cause the server to do a recursive lookup, and then blast away at the ...


13

In short, your are being MITMed. The censor you're facing is doing something to your DNS requests directed at 8.8.8.8 so that you get non-genuine responses. There are many ways to achieve this, and different entities execute this censorship by different means. To take a closer look, use your favorite packet capture tool (Wireshark or tcpdump). As a ...


9

I agree with Steffen, this sounds like malvertising as the most likely cause, with a less likely option being compromise of the visited site with embedded redirects. Running ad-blockers and script-blockers is effective against most malvertising, but can negatively affect your browsing experience. Sometimes malvertising is targeted at only certain browsers. ...


8

This is a genuine Microsoft Update site. If you go to any Microsoft KB article you'll see the link in the INTRODUCTION section (example). All old Windows Update addresses such as windowsupdate.microsoft.com and windowsupdate.com now redirect to the new update.microsoft.com. The new domain seems to be a policy of unifying the update site for Microsoft's ...


8

Blocking IP with no reverse DNS means punishing people who have bad ISP. It seems that most ISP have now understood that reverse DNS should be in place, but occasional mishaps still happen. There is no, to my knowledge, "legitimate" reason not to implement reverse DNS, but I have seen it happen a lot, and rejecting requests on that ground seems harsh, and ...


8

Most likely not. IPv6 support is still quite patchy in many parts of the world. The delay is most likely caused by bad routing or network packets having to go through too many hops. You can test out your IPv6 connection here. The hosts file is used to bypass DNS and make your access to websites matching domains listed slightly faster, not slower. A whois ...


7

We can but... At the point the query makes it to your server it's already too late. Your server will waste its resources trying to do something with the packets and the requests. Even if you have something like iptables drop all connections it's still going to use up all of the bandwidth on the server inbound. Redirecting all traffic someplace else eats up ...


7

Properly used https can mitigate the risk of not using DNSSsec because it is checked if the endpoint is the expected one by validating its certificate. Also, the data transport itself is protected. There are several things which can go wrong with https itself (weak ciphers, errors in validation process, too much trusted root CAs with same rights....) but if ...


7

If the service provides a web interface it might be vulnerable to CSRF attacks, XSS attacks or "same site" scripting. All of these can be triggered by just visiting the attackers external website, which by itself might be caused by malvertising or phishing. For these attacks it does not matter if the service is listening only on localhost, because it is only ...


6

Yes, DNSSEC is immune to this kind of attack. Starting at an anchor (usually the root, sometimes DLV), every delegation is either explicitly secure (presence of DS set on delegation): powerdns.com. 172800 IN NS powerdnssec1.ds9a.nl. powerdns.com. 172800 IN NS powerdnssec2.ds9a.nl. powerdns.com. 86400 IN DS 44030 8 3 ...


6

It depends a lot on the router. Most household/everyday routers don't have the capability to implement local DNS like you're referring to. See here: https://superuser.com/questions/311877/why-do-most-routers-not-include-local-dns If you want to do something client side, you could play around with network shortcuts that map to media servers and the like when ...


6

It solves integrity guarantee. It will no longer be possible to MITM a signed zone. Right now anyone could falsify DNS records, with DNSSEC they cannot. The client already knows the public key of the root zone and can verify the whole chain down to the zone. When you register a domain, you must tell the TLD zone where your nameservers live. At that point, ...


5

The Open Resolver Projects tries to find recursive DNS servers which have no access lists to restrict which clients can use the nameserver. Nameservers like these can be used for DNS amplification attacks because they can be mislead using spoofed IP addresses for DNS queries. The attacker forges the source of the query to the address of its victim. The ...


5

Obviously the implications are going to be implementation-dependent. The NAT device is free to choose any source port desired, and some implementations may have historically used sequential port numbering. But with newer hardware this is becomming increasingly unlikely. Specifically, newer routers prefer to use the client computer's original source port (...


5

You might have hit the "Google Global Cache" where servers are placed on your ISPs network to provide lower-latency access to commonly used resources. The fact that visiting that IP address in a browser gives the Google search page reinforces this likelihood. As for trusting IP addresses: don't. Always use protocols protected by strong end-to-end ...


5

1. What is the goal of DNSSEC? DNSSEC signs DNS records. It does not encrypt, it just confirms authenticity. The root signs keys from TLDs (such as .org or .de), TLDs sign keys from registrars, and registrars sign the DNS records that you (probably) put in via their web interface.[2] You can also have them sign your keys so that you can maintain a signed ...


4

Suppose foo.com has the IP address 11.11.11.11. With DNS spoofing, you worry that foo.com will not correctly resolve to 11.11.11.11, because an attacker has fooled you into thinking its IP address is 22.22.22.22. In this case, your problem is that the domain record you have doesn't point to the IP address you really want. Now, imagine you always enter 11....


4

The problem is that you need to drop the traffic before it reaches your network. So even when dropping packets at your server is way too late. The best way to reduce risk is to use packet scrubbing services like Akamai or Cloudfare who have DDoS mitigation techniques in place to prevent this traffic from reaching your network.


4

From looking at the source, I am going to wager that one potential reason is due to the fact that the user has the option to spoof the source IP address that is sending the malicious DNS requests and responses. If one was using the target name server to retrieve information, they would need to make requests from their true IP in order to receive responses. ...


Only top voted, non community-wiki answers of a minimum length are eligible