Tag Info

New answers tagged

4

"The attacker registers a domain (such as attacker.com) and delegates it to a DNS server he controls. The server is configured to respond with a very short time to live (TTL) record, preventing the response from being cached. When the victim browses to the malicious domain, the attacker's DNS server first responds with the IP address of a server hosting the ...


1

Nope, I don't think there are any vulnerabilities. A google search turned up this article from 2005 which suggests that your customers might use the wildcard to generate semi-convincing URLs(e.g. http://barclays.co.uk|snc9d8ynusnes89g8z.domain.com) for phishing attacks. Nevertheless, I dont think its something to worry about. link : ...


0

If you have a rooted Android connected over WiFi, dsploit is an excellent tool. It can perform active attacks of various kinds, as well as network scans. MITM with sslstrip and content substitution is an option. http://www.dsploit.net/


0

You might be interested in the WiFi Pineapple from Hak5, which provides turn-key MitM functionality. Troy Hunt has a helpful quick start guide.


0

I think some responders made this a bit too complicated. You can shove the link into an iframe and have the iframe loaded into a webpage on mydomain.com. Example: cd /var/www/html/mydomain.com/ vi /var/www/html/mydomain.com/login.html On the login page, you can just insert the other site in an iframe: <iframe ...


1

DNS A record setup with a domain name will work as expected to mask to IP address from view. You will still need :89 after the hostname. DNS translates IP address (layer 3 protocol) Port number cannot be masked (layer 4 protocol)


0

Yeah it sounds like you just want to setup your first-server as a reverseproxy i.e. on mydomain-llc.com you just need in config ProxyPass /login/ http://x.y.z.t:89/ ProxyPassReverse /login/ http://x.y.z.t:89/ Now when people go to http://mydomain-llc.com/login/ their traffic will go through mydomain-llc to x.y.z.t, masking the IP and port from ...


3

As you mentioned, you can mask the IP address through DNS. However, there's nothing you can do to mask the port: the decision to display it or not is entirely up to the user's web browser. There are no security implications of exposing the address and port, though: it's trivial for a potential attacker to figure them out.


1

When the default DNS server of your internet provider doesn't give you the results you expect, you could set a different one in your operating systems network settings. Here is a list of IP addresses of public DNS servers. When you need help with setting a DNS server in your operating system, consult the appropriate stackexchange.


1

It turns out that the DNS system has been hijacked by yandex in cooperation with turk telekom (TTNET) which in turn results in non resolving pages end up on the yandex landing page.


0

When you aren't sure you can trust your ISP, use the HTTPS version of google. When they try to redirect your request to a fake site, you will get a warning that the certificate isn't valid. You should in fact do this for any website. The browser extension HTTPS everywhere can help you with this. It automatically redirects you to the HTTPS version of a ...


1

This ip, when accessed through https, provides a valid certificate for Google.com, so either this server is managed by Google or the ISP is doing a passthrough for HTTPS. Given that it serves a google certificate when accessing by ip, I lean towards it being a Google server. In both cases, using https will ensure that you are communicating with the real ...


4

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


4

Kaminsky attack is a technique with which you can flood the DNS recursive server (like your gateway) with DNS replies that ultimately match the response that the recursive server is originally looking for. This is also called DNS cache poisoning. An alternate technique would be to ARP-spoof your IP as the gateway and let everyone make the DNS query to a DNS ...


1

(Yes, the question is old, but it deserves an answer.) Some rules for modern crypto: MD5 is dead 1024 bit RSA is dead SHA1 is dying Using an HMAC for DNSSEC makes no sense, an HMAC requires both parties to have access to the same secret; in the context of DNSSEC, this means clients could spoof the server, making it useless. There's a lot of algorithms ...



Top 50 recent answers are included