Tag Info

Hot answers tagged

15

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 ...


11

DNSSEC and DNSCurve address completely different aspects of DNS security. First of all, DNSSEC does NOT sign your queries. Rather DNSSEC allows a zone (such as a domain) to be signed by its owner, and allows a resolver (for instance, Comcast's DNS servers) to verify the signature, and therefore be sure that the zone data it gets is authentic. It protects ...


10

DNSSec is normal DNS, but with signatures. It absolutely prevents DNS Spoofing; that's what it's for, and that's what it does. Registrars can still theoretically abuse their position because they're responsible for communicating your intentions to the root servers. This includes information about your DNSSec keys. This relationship will never change; if ...


9

DNS Zone transfer is the process where a DNS server passes a copy of part of it's database (a zone) to another DNS server. It's how you can have more than one DNS server able to answer queries about a particular zone; there is a Master DNS server, and Slave DNS servers, and the slave asks he master for a copy of the records for that zone. A basic DNS Zone ...


8

If the victim is using an open wireless network, spoofing DNS is easy. It is easy for the attacker to mount a man-in-the-middle attack and send forged DNS responses. Therefore, if you are using an open wireless network, you should not trust DNS at all: it is trivial to spoof. Similarly, if the attacker is on the same subnet as you, spoofing DNS is easy: ...


8

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 ...


7

Let's suppose that someone (Mario) wants to send an email to someone else (let's call him Nicolas). Nicolas' mailbox is filled by a unique server, let's say smtp.gouv.fr (that's a fictitious example). So, whatever Mario does, the email will have to go through that server, transmitted with the SMTP protocol (the one with the 'RCPT' command). Mario would like ...


6

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 ...


5

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 ...


5

This is very dangerous. If someone has control over your DNS they can, for example, steal all your email or your web traffic. First, do you operate your own DNS servers, or are they hosted (e.g. at a hosting provider or at your registrar)? Hosted: Check the control panel for these extra entries. They may be prepopulated to point to the host's servers. If ...


5

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 ...


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. ...


4

To complete what @Adnan says: yes, the page is legitimate, however, it is an HTTP-only page, so it could potentially be hijacked (without HTTPS, attackers have ways to present you with fake pages), although it is rather unclear what an attacker could gain that way. Either way, using the menu entry to reach the update site is safe from external interference ...


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 ...


3

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 ...


3

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.


3

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 ...


3

In a technical sense, DNS is easy to spoof. It (almost always) uses UDP as the transport protocol, which is trivial to spoof compared to TCP. And DNS itself offers no precautions against spoofing, so if the attacker can return their own packet first, they win. Note that DNSSEC is designed to address this issue and a couple of others. Successful DNS ...


3

Many DSL modems are open from the WAN side for use by the telecompanies (you can try telneting from the wan side and see if it's open on your modem, try default username/passwors [1]), while it could have been the ISP that changed the DNS-servers it seems unlikely as the IPs are not in the same range. Like you said, the most likely intrusion vector is a ...


3

DNS requests and replies are not HTTP; they are... DNS. See the standard. Most of the time, DNS requests and responses use UDP: the request is a single IP packet, and so is the response. With UDP, each packet is identified by: the source IP address the destination IP address the source port the destination port A DNS request from client C to DNS server ...


2

Can you tell who created the entries? Do you have access to edit your zone file? You might try checking those entries on the outside web and also internally. It could be an issue with your internal DNS server. If someone has access to create a ww or wwww then there is no reason that they can't redirect the real www address.


2

@GrahamHill already explained a zone transfer pretty good already, but I'll try to fill inn some more. By being able to query for all records from the DNS server, the attacker can easily determine which machines are accessible. The zone transfer may reveal network elements that is accessible from the Internet, but that a search engine like Google ...


2

It depends on the device doing the NAT. Most sophisticated firewalls have fingerprint scrambling features that can be enabled, for example Checkpoint has had those features since NG I believe, so a good 10 years. A basic router will not do fingerprint scrambling, it will just use the source port in the TCP packet. Some few network devices will actually map ...


2

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 ...


2

ARP poisoning causes the traffic between those hosts to be forwarded through you, as part of the man in the middle attack. This causes performance degradation on the targets for a few reasons: There is increased latency due to the added network hop. Your network card has to send and receive 2 to 4 times as much data as normal, since you're acting as a ...


2

Assuming the VPN is setup securely, this gives good protection against WiFi attacks. You're right that any traffic needed to setup the VPN will go directly on the WiFi. DNS spoofing could happen during VPN setup. Depending on the exact setup of your VPN, the VPN may have protection against this (by server certificate or shared secret) - or it may not. As I ...


1

your calculation seems to be simplified. According to the formula given in RFC 5452, the number of fake packets 'F' that are candidates to be accepted is given by : P_s = D * R * W / ( N * P * I ) where I is the number distinct IDs available (which is 65536 in your case), P is the number of ports used, N is the number of authoritative nameservers for a ...


1

This functionality is what they call Split-tunneling. When "Send All Traffic to VPN" is enabled, this allows your local network traffic to not be routed across the VPN. The idea for this is to prevent your locally routed network from being sent across the VPN. Long story short, if you enable this, all your traffic will be encrypted by the VPN tunnel. Local ...


1

The uplink will still be saturated. The only way to mitigate this is to turn on RRL on servers and get ride of open resolvers. And for legitimate open resolvers, have them send UDP packets as small as possible with the TC bit set ("please retry using TCP") so that amplification doesn't happen yet it doesn't break legitimate traffic. Other mitigation ...


1

There are a lot of factors which play an important role in DNS poisoning but most probably the main one is timing. Using the same source port over and over again gives the attacker a huge time boost advantage, as he already knows the port he needs to send his queries to. If an attacker, with a rogue DNS server is able to reply to your request in a faster ...



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