Re: SPF Configurations
On Sun, 6 Dec 2009, Bill Stewart wrote: On Sun, Dec 6, 2009 at 2:56 PM, Sean Donelan wrote: In particular, what anti-forgery/security controls should network operators implement and check; and what anti-forgery/security controls should network operators not implement or check? Depends a bit on whether you're counting inbound-mail-service operators as network operators. Because this is NANOG, I was scoping it to be just layer 0 to 4. Leaving the application and above layer discussions to other places. I would love to know how the marketplace wants to handle "Official Mail," but I'm not expecting useful answers here. As an end user who doesn't have an account at Bank of America, I'd be happy if bankofamerica.com used SPF records so my mail system could discard forged spam from them; that's much different than the kind of forgery prevention I want for my actual bank. (And obviously SPF isn't going to stop mail from bank0vamer1ca.cm etc., but it can cut down some of the noise and leave the rest for Spamassassin.) Like most things, scaling is the only problem. Your Bank is different from My Bank, and His Bank and Her Bank, and so on. Throw in multiple middle-parties, i.e. the NSP, ISP, MSP, ESP, etc; and the problem becomes very difficult. And that's before adding the problem the real Your Bank (or their marketing partners, or their compromised PCs) may also send stuff you don't want. Network operations probably aren't going to solve those problems. And lots of other places like to discuss them. So instead, what things should network operators be expected to solve? If you can't trust routing, can you trust DNS? If you can't trust DNS, can you trust things using DNS? If you can't trust ???, can you trust ???
RE: Historical traceroute logging
Smokeping has SmokeTrace http://oss.oetiker.ch/smokeping/ New in Version 2.4 (The SmokeTrace edition) SmokeTrace: An Ajax Traceroute tool. Try the demo. SmokeTrace is written in javascript, using the qooxdoo framework, which is responsible for all the cross browser glory. This may be what you are looking for. Christian Liendo New York Times Digital
Re: news from Google
Google has got a lot of data centers around the world, but the DNS servers are located in some of these. There is the list of data centers with DNS servers: USA, Atlanta USA, Reston,VA USA, Seattle USA, California Brazil, Sao Paulo Taiwan, Taipei City Germany, Frankfurt/Main Netherlands, Groningen Ireland, Dublin United Kingdom, London (anywhere else?) Here you can check ping distance to 8.8.8.8 from the servers all over the world: http://www.wipmania.com/ping/cache/8.8.8.8/?c=f4335d8443172 Regards, Alex 2009/12/3 Eduardo A. Suárez > Hi, > > now Google DNS, anything more? > > > http://googlecode.blogspot.com/2009/12/introducing-google-public-dns-new-dns.html > > Eduardo.- > >
Re: SPF Configurations
> The problem we face is that some people we work with can't do that Then explain that client-side (their users, to whom they send mail) are probably using Hotmail, et.al. and SPF will simply not allow "spoofing" which is what they want to do, unless they either : A) add the SPF record as previously mentioned. It's a TXT record under their root and isn't hard at all. B) permit you to use a subdomain (like "u...@theircompanymail.yourdomain.com"). A variant of (B) would be to ask them if you can register "theircompanymail.[com|net|..]" and send from that with proper SPF records. Most people won't notice the difference. We run into this all the time (a .edu) where users decide they want to use Yahoo for their email (we let them do that) .. but then configure their @edu address as the FROM and wonder why nobody gets their email. (we have to constantly explain how "NO, we won't add Yahoo's mail servers to our SPF record") Personally, I think SPF is a major PITA operations-wise .. but if you've ever had to fill out the form to get un-blacklisted at Yahoo/AOL, that's one of the first things they ask .. "do you have a spfv1 record defined?". As an aside, allowing your customers to forward @yourdomain to @otherdomain .. is a good way to get your own MXs blacklisted (this happens to us about once a month, then the "free whatever" adds blast our @edu addresses and a third of them go off to Yahoo .. our spam filters catch most of it, but then they miss a batch, we always have problems because of the forwards.) Regards, Michael Holstein Cleveland State University
Re: news from Google
>> >> now Google DNS, anything more? >> >> http://googlecode.blogspot.com/2009/12/introducing-google-public-dns-new-dns.html > Probably in support of their various Android netbooks that are in the pipe. They'll likely come pre-configured to use GoogleDNS .. that way they won't (accidentally) loose ad/search revenue when a "helpful" ISP redirects NXDOMAIN responses. Will be interesting to see if ISPs respond to a large scale thing like this taking hold by blocking UDP/TCP 53 like many now do with tcp/25 (albeit for other reasons). Therein lies the problem with some of the "net neturality" arguments .. there's a big difference between "doing it because it causes a problem for others", and "doing it because it robs me of revenue opportunities". Cheers, Michael Holstein Cleveland State University
Re: SPF Configurations
On Dec 7, 2009, at 9:51 AM, Michael Holstein wrote: > >> The problem we face is that some people we work with can't do that > > Then explain that client-side (their users, to whom they send mail) are > probably using Hotmail, et.al. and SPF will simply not allow "spoofing" which > is what they want to do, unless they either : > > A) add the SPF record as previously mentioned. It's a TXT record under their > root and isn't hard at all. An authorization tied to a PRA or Mail From will not prevent spoofing, it just constrains the risks to those with access to a provider's service. A provider could insure a user controls the From email-address, but this would conflict with the IP path registration schemes. > B) permit you to use a subdomain (like > "u...@theircompanymail.yourdomain.com"). A provider can ensure any signed From email-address is controlled by its users by using ping-back email confirmations appended to user profiles. There is a proposal aimed at reducing DNS overhead and scalability issues associated with the all-inclusive IP address path registration scheme with its inability to cope with forwarded email: http://tools.ietf.org/html/draft-otis-dkim-tpa-label-03 Use of this DKIM extension can safely accommodate a user's desire to authorize third-party signatures to protect acceptance of From headers within domains that differ from the DKIM signature. DKIM does not need to change. Once IPv6 and international TLDs come into the mix, having users "vote" (authorize) DKIM providers could better determine what new domains can be trusted, and help ensure users are allowed to utilize their own language and to seek assistance in obtaining acceptable IPv6 connectivity. -Doug
Re: SPF Configurations
On Mon, Dec 7, 2009 at 11:21 PM, Michael Holstein wrote: > > Personally, I think SPF is a major PITA operations-wise .. but if you've > ever had to fill out the form to get un-blacklisted at Yahoo/AOL, that's > one of the first things they ask .. "do you have a spfv1 record defined?". With yahoo and aol - they'd be just as satisfied if you used, say, DKIM. Hotmail's the only one that insists on sender-id (not spfv1 either) As for a university smarthost getting blocked you'd probably need to look at one of two things - 1. Forwarding users on your campus - with mailboxes that accept a lot of spam and then forward it over to student / alumni AOL, Comcast, Yahoo etc accounts 2. Spam generated by infected PCs / laptops, hacked machines etc on your campus LAN If you took steps to fix some of these - 1. Isolate your forwarding through a separate IP or subnet, filter it before forwarding on 2. Separate your outbound to another set of IPs, again filter and a few other things - related to this .. you'd get blocked far less. Joe St.Sauver of UOregon, being a maawg senior tech advisor and also active in EDUCAUSE etc, might have a white paper on this, like he does on most other security related issues under the sun :) -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: Official Mail, was SPF Configurations
>I would love to know how the marketplace wants to handle "Official Mail," >but I'm not expecting useful answers here. The marketplace doesn't have a clue. We have a plenty of tools in the toolbox, from heavyweight S/MIME to lighter weight DKIM+VBR to proprietary Goodmail, but among the mailers with a stake in having a reliable spoof-resistant channel I don't see much interest in doing anything other than whatever they're doing now. If it were up to me, I'd use per-recipient password-protected RSS or Atom feeds with emailed notices that just say to check your feed, but that has patent issues. R's, John
Re: random DNS, was news from Google
>Will be interesting to see if ISPs respond to a large scale thing like >this taking hold by blocking UDP/TCP 53 like many now do with tcp/25 >(albeit for other reasons). Therein lies the problem with some of the >"net neturality" arguments .. there's a big difference between "doing it >because it causes a problem for others", and "doing it because it robs >me of revenue opportunities". I do hear of ISPs blocking requests to random offsite DNS servers. For most consumer PCs, that's more likely to be a zombie doing DNS hijacking than anything legitimate. If they happen also to block 8.8.8.8 that's just an incidental side benefit. R's, John
Breaking the internet (hotels, guestnet style)
On Dec 7, 2009, at 5:29 PM, John Levine wrote: >> Will be interesting to see if ISPs respond to a large scale thing like >> this taking hold by blocking UDP/TCP 53 like many now do with tcp/25 >> (albeit for other reasons). Therein lies the problem with some of the >> "net neturality" arguments .. there's a big difference between "doing it >> because it causes a problem for others", and "doing it because it robs >> me of revenue opportunities". > > I do hear of ISPs blocking requests to random offsite DNS servers. > For most consumer PCs, that's more likely to be a zombie doing DNS > hijacking than anything legitimate. If they happen also to block > 8.8.8.8 that's just an incidental side benefit. I've found more and more hotel/edge networks blocking/capturing this traffic. The biggest problem is they tend to break things horribly and fail things like the oarc entropy test. They will often also return REFUSED (randomly) to valid well formed DNS queries. While I support the capturing of malware compromised machines until they are repaired, I do think more intelligence needs to be applied when directing these systems. Internet access in a hotel does not mean just UDP/53 to their selected hosts plus TCP/80, TCP/443. The University of Michigan Hospitals have a guestnet wireless that is ghetto and blocks IMAP over SSL. Attempts to get them to correct this have fallen on deaf ears. I can't even VPN out to work around the sillyness, which typically works in other hotel/guestnet scenarios. Providers to avoid: US Signal Corporation. (64.141.138.226 was my natted IP in a Hampton Inn depsite whois/swip). - Jared
Re: Breaking the internet (hotels, guestnet style)
Jared Mauch wrote: The University of Michigan Hospitals have a guestnet wireless that is ghetto and blocks IMAP over SSL. Attempts to get them to correct this have fallen on deaf ears. I can't even VPN out to work around the sillyness, which typically works in other hotel/guestnet scenarios. Providers to avoid: US Signal Corporation. (64.141.138.226 was my natted IP in a Hampton Inn depsite whois/swip). - Jared I'm pretty sure that's the hotel doing the blocking, USS isn't the type to enforce anything specific like that that I've found as they're a wholesaler and blocking that stuff tends to annoy those who are whiteboxing their product. They definitely don't do anything like that on their transit links. -Paul
Re: Breaking the internet (hotels, guestnet style)
On 12/7/09 4:00 PM, Jared Mauch wrote: Providers to avoid: US Signal Corporation. (64.141.138.226 was my natted IP in a Hampton Inn depsite whois/swip). Add Air2Data (seen in Best Western in WY). 20 someodd APs, all routerboards, all same SSID, overlapping channels, hijacking 80 and 53. When using PPTP or IPSec VPN, the AP chokes and locks out all other clients, eventually stops responding completely. SpeedLinks (once again, Best Western, in Tacoma, WA) was almost as bad. Port 53 hijacking, flakey PPTP support, no ethernet jacks. I'm noticing alot of these places are doing things which work perfectly with Windows, but not Mac, Linux, etc. Drives me bonkers, and we make sure to let management know we won't stay at their hotel in the future because of said issues. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
Re: Breaking the internet (hotels, guestnet style)
On Dec 7, 2009, at 7:23 PM, Brielle Bruns wrote: > I'm noticing alot of these places are doing things which work perfectly with > Windows, but not Mac, Linux, etc. Drives me bonkers, and we make sure to let > management know we won't stay at their hotel in the future because of said > issues. I'd prefer to not create a blacklist of hotels that have ghetto internet access, but perhaps this is something we can aggregate? I'm mostly tired of people saying the internet is http(s) only. Even had hotels in Japan do some really nasty things... - Jared
Re: Breaking the internet (hotels, guestnet style)
Swisscom Eurospot - found all through europe and ruinously expensive at like 25 euro a day, 9 euro an hour See http://www.mcabee.org/lists/nanog/Feb-07/msg00046.html for what goes on there .. dns proxying, and broken at that. On Tue, Dec 8, 2009 at 6:08 AM, Jared Mauch wrote: > > On Dec 7, 2009, at 7:23 PM, Brielle Bruns wrote: > >> I'm noticing alot of these places are doing things which work perfectly with >> Windows, but not Mac, Linux, etc. Drives me bonkers, and we make sure to >> let management know we won't stay at their hotel in the future because of >> said issues. > > I'd prefer to not create a blacklist of hotels that have ghetto internet > access, but perhaps this is something we can aggregate? > > I'm mostly tired of people saying the internet is http(s) only. Even had > hotels in Japan do some really nasty things... > > - Jared > -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: Breaking the internet (hotels, guestnet style)
Disclaimer: /I work for a company that provides these services./ IMHO there is no need for any sort of DNS redirection after user authentication has taken place. We of course redirect UDP/TCP 53 to one of our servers along with 80 (http) 443 (https) 8080, 3128 (proxy) to the local hotspot *before* any authentication has occurred, but once this is completed the only reason any guest would use the local DNS server is if they were assigned a DHCP address. As far as our Routerboard/Mikrotik setup works, it'll masquerade for any non standard IP addresses that appear on the network (guests with static ip's assigned, corporate laptops etc) but once again after the authentication stage anything is allowed to pass unhindered. The only redirection that is used after authentication is for port 25 as 90% of user trying to send mail out via port 25 have no idea how to change their mail server, let alone why they might need to. It can be an issue as some systems use authentication on port 25. I would be interested to hear what people have to say about this, as the only other option I could think of would involve checking the incoming connection to see if the end user was trying to authenticate to a mail server before determining where to forward the connection onto (Layer 7 stuff, gets a bit tricky) Regards, Andrew Cox AccessPlus Head Network Administrator Jared Mauch wrote: On Dec 7, 2009, at 5:29 PM, John Levine wrote: Will be interesting to see if ISPs respond to a large scale thing like this taking hold by blocking UDP/TCP 53 like many now do with tcp/25 (albeit for other reasons). Therein lies the problem with some of the "net neturality" arguments .. there's a big difference between "doing it because it causes a problem for others", and "doing it because it robs me of revenue opportunities". I do hear of ISPs blocking requests to random offsite DNS servers. For most consumer PCs, that's more likely to be a zombie doing DNS hijacking than anything legitimate. If they happen also to block 8.8.8.8 that's just an incidental side benefit. I've found more and more hotel/edge networks blocking/capturing this traffic. The biggest problem is they tend to break things horribly and fail things like the oarc entropy test. They will often also return REFUSED (randomly) to valid well formed DNS queries. While I support the capturing of malware compromised machines until they are repaired, I do think more intelligence needs to be applied when directing these systems. Internet access in a hotel does not mean just UDP/53 to their selected hosts plus TCP/80, TCP/443. The University of Michigan Hospitals have a guestnet wireless that is ghetto and blocks IMAP over SSL. Attempts to get them to correct this have fallen on deaf ears. I can't even VPN out to work around the sillyness, which typically works in other hotel/guestnet scenarios. Providers to avoid: US Signal Corporation. (64.141.138.226 was my natted IP in a Hampton Inn depsite whois/swip). - Jared
Re: Breaking the internet (hotels, guestnet style)
You could just firewall off port 25 and leave 587 open - to save yourself from a bunch of viruses and such. A lot of people will use webmail anyway - from a hotel. And you avoid getting blacklisted The other option is to install a device that examines email flows and allows only stuff it doesnt think is spammy (netflow for email kind of, with all the bayesian etc secret sauce). Two devices come to mind * Symantec E160 (used to be called turntide, and before that, back in 2002-03, spam squelcher) * Mailchannels (www.mailchannels.com) There's probably a few more that do this and are totally transparent. On Tue, Dec 8, 2009 at 6:54 AM, Andrew Cox wrote: > > I would be interested to hear what people have to say about this, as the > only other option I could think of would involve checking the incoming > connection to see if the end user was trying to authenticate to a mail > server before determining where to forward the connection onto (Layer 7 > stuff, gets a bit tricky) -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: Breaking the internet (hotels, guestnet style)
Suresh Ramasubramanian wrote: You could just firewall off port 25 and leave 587 open - to save yourself from a bunch of viruses and such. A lot of people will use webmail anyway - from a hotel. And you avoid getting blacklisted The problem with doing that is that users don't understand it. All they know is that "it doesn't work here and it does at home". We currently redirect to a couple of dedicated mail relays that will accept any email where: a) the source address = the email address the put on their signup and b) is not detected as spam Alternatively there's a throttling table and spam filter on everything else that comes through. The other option is to install a device that examines email flows and allows only stuff it doesnt think is spammy (netflow for email kind of, with all the bayesian etc secret sauce). Two devices come to mind * Symantec E160 (used to be called turntide, and before that, back in 2002-03, spam squelcher) * Mailchannels (www.mailchannels.com) There's probably a few more that do this and are totally transparent. We can also just force the box to accept any unsecured auth-attempts however the SMTPS over port 25 is still a problem. Don't see how any system could examine that mail without causing certificate errors. Allowing it to pass to the original server based on the first packet being detected as a secure connection may be possible thou. On Tue, Dec 8, 2009 at 6:54 AM, Andrew Cox wrote: I would be interested to hear what people have to say about this, as the only other option I could think of would involve checking the incoming connection to see if the end user was trying to authenticate to a mail server before determining where to forward the connection onto (Layer 7 stuff, gets a bit tricky)
Re: Breaking the internet (hotels, guestnet style)
On Dec 7, 2009, at 6:00 PM, Jared Mauch wrote: > > On Dec 7, 2009, at 5:29 PM, John Levine wrote: > >>> Will be interesting to see if ISPs respond to a large scale thing like >>> this taking hold by blocking UDP/TCP 53 like many now do with tcp/25 >>> (albeit for other reasons). Therein lies the problem with some of the >>> "net neturality" arguments .. there's a big difference between "doing it >>> because it causes a problem for others", and "doing it because it robs >>> me of revenue opportunities". >> >> I do hear of ISPs blocking requests to random offsite DNS servers. >> For most consumer PCs, that's more likely to be a zombie doing DNS >> hijacking than anything legitimate. If they happen also to block >> 8.8.8.8 that's just an incidental side benefit. > > I've found more and more hotel/edge networks blocking/capturing this traffic. > > The biggest problem is they tend to break things horribly and fail things > like the > oarc entropy test. > > They will often also return REFUSED (randomly) to valid well formed DNS > queries. > > While I support the capturing of malware compromised machines until they are > repaired, I do think more intelligence needs to be applied when directing > these systems. > > Internet access in a hotel does not mean just UDP/53 to their selected hosts > plus TCP/80, > TCP/443. It's why I run an ssh server on 443 somewhere -- and as needed, I ssh-tunnel http to a squid proxy, smtp, and as many IMAP/SSL connections as I really need... --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: Breaking the internet (hotels, guestnet style)
On Mon, Dec 07, 2009 at 09:48:25PM -0500, Steven Bellovin wrote: > > On Dec 7, 2009, at 6:00 PM, Jared Mauch wrote: > > > > > On Dec 7, 2009, at 5:29 PM, John Levine wrote: > > > >>> Will be interesting to see if ISPs respond to a large scale thing like > >>> this taking hold by blocking UDP/TCP 53 like many now do with tcp/25 > >>> (albeit for other reasons). Therein lies the problem with some of the > >>> "net neturality" arguments .. there's a big difference between "doing it > >>> because it causes a problem for others", and "doing it because it robs > >>> me of revenue opportunities". > >> > >> I do hear of ISPs blocking requests to random offsite DNS servers. > >> For most consumer PCs, that's more likely to be a zombie doing DNS > >> hijacking than anything legitimate. If they happen also to block > >> 8.8.8.8 that's just an incidental side benefit. > > > > I've found more and more hotel/edge networks blocking/capturing this > > traffic. > > > > The biggest problem is they tend to break things horribly and fail things > > like the > > oarc entropy test. > > > > They will often also return REFUSED (randomly) to valid well formed DNS > > queries. > > > > While I support the capturing of malware compromised machines until they are > > repaired, I do think more intelligence needs to be applied when directing > > these systems. > > > > Internet access in a hotel does not mean just UDP/53 to their selected > > hosts plus TCP/80, > > TCP/443. > > It's why I run an ssh server on 443 somewhere -- and as needed, I ssh-tunnel > http to a squid proxy, smtp, and as many IMAP/SSL connections as I really > need... ^ me too, as well on on port 80 > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > > > > > -- -=[L]=- Our core competencies are office moves and vocabulary.
Re: Breaking the internet (hotels, guestnet style)
> IMHO there is no need for any sort of DNS redirection after user > authentication has taken place. It may be hazardous even before user authentication has taken place. Even given a very low TTL, client resolvers may cache answers returned during that initial authentication. > We of course redirect UDP/TCP 53 to one of our servers along with 80 > (http) 443 (https) 8080, 3128 (proxy) to the local hotspot *before* any > authentication has occurred, but once this is completed the only reason > any guest would use the local DNS server is if they were assigned a DHCP > address. Which, presumably, many/most of them are. Supplying a functional DNS server shouldn't be that difficult, but real world experience shows just how well some operators run these services. > As far as our Routerboard/Mikrotik setup works, it'll masquerade for any > non standard IP addresses that appear on the network (guests with static > ip's assigned, corporate laptops etc) but once again after the > authentication stage anything is allowed to pass unhindered. > > The only redirection that is used after authentication is for port 25 as > 90% of user trying to send mail out via port 25 have no idea how to > change their mail server, let alone why they might need to. > It can be an issue as some systems use authentication on port 25. Sounds like an opportunity for a custom proxy. Clients that can successfully authenticate to an external mailserver on 25 are probably by definition nonproblematic. The remainder probably deserve to get jammed through an aggressive spam, virus, and other-crap filter, with in-line notification of rejections. You can do some other sanity stuff like counting the number of hosts contacted by a client; anything in excess of a small number would seem to be a good indicator to stop. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: Breaking the internet (hotels, guestnet style)
It's why I run an ssh server on 443 somewhere -- and as needed, I ssh-tunnel http to a squid proxy, smtp, and as many IMAP/SSL connections as I really need... Same here. It's the most reliable way to break out of a hotel jail. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly.
Re: news from Google
Martin Hannigan expunged (mar...@theicelandguy.com): > > Why did Google put an infrastructure critical application into PA space? > I'm not sure what the policy is now, but it seemed that when I was at L3 (losing my memory at this point) 4/8 was used as PA space and 8/8 was basically handed out as PI space. I could be wrong... -Steve
Re: Breaking the internet (hotels, guestnet style)
On Dec 7, 2009, at 10:35 PM, John R. Levine wrote: >> It's why I run an ssh server on 443 somewhere -- and as needed, I ssh-tunnel >> http to a squid proxy, smtp, and as many IMAP/SSL connections as I really >> need... > > Same here. It's the most reliable way to break out of a hotel jail. Funny enough, I happen to be staying at a Marriott this week, where apparently I can't do ANYTHING on this network (my iChat client won't even connect!). Just so happens that I brought my Xbox360 this week and plugged it into the TV to get some Modern Warfare 2 on, and of course, THAT wasn't going to work on the network either right? Right. So, I broke out my Mifi (from Verizon). Connected my xbox360 to my mifi and played some Call of Duty. No lag. Okay, I feel better, done ranting against stayonline and guestnet. J
Re: Breaking the internet (hotels, guestnet style)
On Dec 7, 2009, at 10:18 PM, Lou Katz wrote: > On Mon, Dec 07, 2009 at 09:48:25PM -0500, Steven Bellovin wrote: >> >> On Dec 7, 2009, at 6:00 PM, Jared Mauch wrote: >> >>> >>> On Dec 7, 2009, at 5:29 PM, John Levine wrote: >>> > Will be interesting to see if ISPs respond to a large scale thing like > this taking hold by blocking UDP/TCP 53 like many now do with tcp/25 > (albeit for other reasons). Therein lies the problem with some of the > "net neturality" arguments .. there's a big difference between "doing it > because it causes a problem for others", and "doing it because it robs > me of revenue opportunities". I do hear of ISPs blocking requests to random offsite DNS servers. For most consumer PCs, that's more likely to be a zombie doing DNS hijacking than anything legitimate. If they happen also to block 8.8.8.8 that's just an incidental side benefit. >>> >>> I've found more and more hotel/edge networks blocking/capturing this >>> traffic. >>> >>> The biggest problem is they tend to break things horribly and fail things >>> like the >>> oarc entropy test. >>> >>> They will often also return REFUSED (randomly) to valid well formed DNS >>> queries. >>> >>> While I support the capturing of malware compromised machines until they are >>> repaired, I do think more intelligence needs to be applied when directing >>> these systems. >>> >>> Internet access in a hotel does not mean just UDP/53 to their selected >>> hosts plus TCP/80, >>> TCP/443. >> >> It's why I run an ssh server on 443 somewhere -- and as needed, I ssh-tunnel >> http to a squid proxy, smtp, and as many IMAP/SSL connections as I really >> need... Also handy to set up an SSH tunnel. That works for almost everything else. J
Re: Breaking the internet (hotels, guestnet style)
In message <200912080332.nb83wkso037...@aurora.sol.net>, Joe Greco writes: > > IMHO there is no need for any sort of DNS redirection after user > > authentication has taken place. > > It may be hazardous even before user authentication has taken place. > Even given a very low TTL, client resolvers may cache answers returned > during that initial authentication. > > > We of course redirect UDP/TCP 53 to one of our servers along with 80 > > (http) 443 (https) 8080, 3128 (proxy) to the local hotspot *before* any > > authentication has occurred, but once this is completed the only reason > > any guest would use the local DNS server is if they were assigned a DHCP > > address. > > Which, presumably, many/most of them are. Supplying a functional DNS > server shouldn't be that difficult, but real world experience shows just > how well some operators run these services. > > > As far as our Routerboard/Mikrotik setup works, it'll masquerade for any > > non standard IP addresses that appear on the network (guests with static > > ip's assigned, corporate laptops etc) but once again after the > > authentication stage anything is allowed to pass unhindered. > > > > The only redirection that is used after authentication is for port 25 as > > 90% of user trying to send mail out via port 25 have no idea how to > > change their mail server, let alone why they might need to. > > It can be an issue as some systems use authentication on port 25. > > Sounds like an opportunity for a custom proxy. Clients that can > successfully authenticate to an external mailserver on 25 are probably > by definition nonproblematic. The remainder probably deserve to get > jammed through an aggressive spam, virus, and other-crap filter, with > in-line notification of rejections. You can do some other sanity stuff > like counting the number of hosts contacted by a client; anything in > excess of a small number would seem to be a good indicator to stop. > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > "We call it the 'one bite at the apple' rule. Give me one chance [and] then I > won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CN > N) > With 24 million small businesses in the US alone, that's way too many apples. > This really should be a DHCP option which points to the authentification server using ip addresses. This should be return to clients even if they don't request it. Web browers could have a hot-spot button that retrieves this option then connects using the value returned. No need to compromise the DNS or intercept http. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
