helpless said:
In this case how would this work? Would the poisoning take place on the users network or on their ISP's? I assume its easier to compromise a corporate network if this is what was being done.
Well, as Karnaugh pointed out, DNS cache poisoning, or DNS spoofing is not an easy thing to do in practice, at least not since the scare in March and April when SANS (
http://www.sans.org) issued a notice about this afer a widespread outbreak, affecting BIND as well as Widows NT and 2000 servers. Their summary can be found here:
http://isc.sans.org/presentations/dnspoisoning.php. I would say it's easier to compromise an internal server (only used in the company) rather than an external one (internet accessible), but it depends on the competence and diligence of the company's Information Security staff.
helpless said:
We have just had a problem with proxy servers in certain areas denying html requests to our server in the States. How would one theoretically go about this?
I assume a user searches for a domain.
This request goes to the users ISP
Its converted by a dns server into an IP address
It gets directed to a proxy server where the page is cached
This is where I get lost:
As an example I understand that Mweb dial up and adsl accounts will access our sites via a proxy serve, That we log the IP address of the proxy if they are interacting online with the site but when they are in read only mode they are looking at cached pages.
How close am I? How would someone go about poisoning this process? What would prevent some proxy servers from processing html pages from our servers and not others? I always understood that these proxy servers are supposed to flush their cache every eight hours or so.
In this case, DNS spoofing isn't the only way to achieve this, you also have to look at the ISP's proxy server. Most ISP's run a transparent proxy, which is supposed to be invisible to the user. The only purpose and effect of such a proxy would be to speed up browsing by serving the page from its cache, instead of from the original server. RFC 2616 (
http://www.w3.org/Protocols/rfc2616/rfc2616.html) describes the HTTP/1.1 protocol, and describes in section 13 how proxy servers should and should not act. Like all RFC's it's not the easiest document in the world to read if you're not familiar with the terminology and concepts.
1) The proxy can have a ACL blocking certain sites (Bad, bad ISP ...). This is highly unlikely, though, especially for a large ISP like MWeb. They can get into a lot of trouble if they start censoring. Also, I may be wrong, but for DSL I believe that MWeb uses the SAIX proxy for DSL and their own for dial-up, which means two different proxy servers needs to be affected.
2) The proxy server or DNS server could be compromised, either changing the cached pages on disk, or some spoofing attack. Again, for a large ISP, very highly unlikely. They are supposed to be very paranoid over security, and the bad press would be devastating. And it would affect all users of the proxy for a certain time period, not just specific geographic areas.
3) There could be a geographically-localized connectivity issue, where the routers involved cannot actually get traffic to/from your site, either because of an issue locally in SA or an international issue. I think this would be the most likely scenario, especially if it resolved itself fairly quickly. As an example, I was on-site at a client (using IS as ISP) on Wednesday when I suddenly couldn't resolve ANY DNS entries any more. This turned out to be due to the 2-hour Telkom cable failure at New Doornfontein.
4) All the users' machines in the area could of course be compromised, but this is also close to impossible. DSL and dial-up gets assigned IPs from different IP pools (One belonging to MWeb and one to SAIX), making compromising VERY hard to do realistically.
Proxy servers needs to remove pages in their cache once one of the following happens:
1) It's out of space to cache (usually works on a last-accessed, first out principle).
2) The page has expired (each page contains a expiry date for proxies. If it doesn't, the proxy can use a heuristic calculation to determine this). In this case it will verify with the original server whether the cached page is current or not.
3) The page can be marked as non-cachable, in which case the proxy should issue a new request to the server for every access to it.
While it is certainly possible to do all this via some compromise of the servers involved, breaking into a machine that's properly updated and protected and secured is not a very easy task, and I think a bit beyond the scope of his thread
But remember that not every anomaly is caused by malicious intent, it could also be due to a temporary misconfiguration, someone accidentaly switching the wrong machine off at the wrong time, plug the right cable into the wrong port, or routine maintenance. Or maybe a physical cable/equipment failure.
As an aside, you can use
http://www.procata.com/cachetest to test how closely your proxy conforms to the HTTP/1.1 specs.
helpless said:
Sorry for being a bit simple.
No problems
Everyone has to start learning somewhere, and I don't mind at all.
