Re: [IP] VeriSign prepares to relaunch Site Finder -- calls
On Tue, 24 Feb 2004, Jason Nealis wrote: FWIW, We had PAXFIRE in over here last week and heard their dog and pony on the product, basically they make money by using your customer base and diverting them to a search page that they developed with their partners. Of course they only divert them on failed www lookups. Okay, they are lying here. There is no way for them to tell if something is a web lookup or some other type of lookup at this point. Unless of course they only divert www.*, and even then other types of services may be provided by a host with a name of www.*. So they really can't make this work without breaking sometihng. bye, ken emery It's a module plug-in into bind and if you prefer to try and do this in a opt-in basis they have a client program that you download and it gets hooked into the users browser. They claim that the embedded MSN search page that you get diverted to by IE is making MSN millions and millions of dollars and they want the ISP's to get some of that revenue share. Jason Nealis RCN INTERNET On Mon, Feb 23, 2004 at 04:54:51PM -0500, Stephen J. Wilcox stated I am curious what the operational impact would be to network operators if, instead of Verisign using SiteFinder over all com and net, Verisign or their technology partner for SiteFinder began coercing a large number of independent ISPs and network operators to install their form of DNS redirection at the ISP-level, until all or most of the end-users out there were getting redirected. It would be no worse than NEW.NET or any other form of DNS pollution/piracy (like the alternate root whackos), as long as it was clearly labelled. As Sorry my threading is screwed, something to do with the headers so I missed half the replies. Anyway I just sent an email, I dont think this is the same as the new.net thing, in that case you have an unstable situation of competing roots arising which as it grows or collides the operator community is left to pick up the pieces and complaints. With a local redirection you get to choose that you want it, you dont impose it on other parts of the Internet and given enough clue level your customers can run their own DNS if they object. So with that in mind this is no worse that http caching/smtp redirection or other local forms of subversion.. Steve an occasional operator of infrastructure, I wouldn't like the complaint load I'd see if the customers of such ISP's thought that *I* was inserting the garbage they were seeing. So I guess my hope is, it'll be opt-in with an explicitly held permission for every affected IP address (perhaps using some kind of service discount or enhancement as the carrot.)
Re: Any 1U - 2U Ethernet switches that can handle 4K VLANs?
On Mon, 26 Jan 2004, Niels Bakker wrote: * [EMAIL PROTECTED] (Jeff Kell) [Mon 26 Jan 2004, 00:35 CET]: Using 3550-48s you can have L3 links between VTP domains. The point of using VLANs is that you don't need to route. There's probably a good reason for switching instead of routing in the original poster's scenario. (Perhaps a FTTH-like project?) Correct me if I'm wrong here, but at some point you will have to route all those VLAN's. To really answer the question about wether 1000 VLAN's are necessary one would need to see the network design. From my point of view I'd have to question the need to carry that many VLAN's over a large portion of the network. I would think that the network should be more partitioned so most of the VLAN's don't need to be seen outside a small area. bye, ken emery
Re: Any 1U - 2U Ethernet switches that can handle 4K VLANs?
On Sun, 25 Jan 2004, Bill Nash wrote: On Sun, 25 Jan 2004, ken emery wrote: The point of using VLANs is that you don't need to route. There's probably a good reason for switching instead of routing in the original poster's scenario. (Perhaps a FTTH-like project?) Correct me if I'm wrong here, but at some point you will have to route all those VLAN's. To really answer the question about wether 1000 VLAN's are necessary one would need to see the network design. I would argue this point. I've got a production environment sporting multiple vlans, none which will ever see an external subnet or even a gateway (think databases.) The operative context inherent in the VLAN acronym is, after all, 'local', and not every topology requires routing. This is correct, but then why spend the money on a L3 switch? Routing isn't needed so save the money and purchase a L2 switch. bye, ken emery
Re: ATT carrying rfc1918 on the as7018 backbone?
On Fri, 23 Jan 2004, Tomas Lund wrote: On Thu, 22 Jan 2004, Brett Watson wrote: I was just having a hard time believing ATT was leaking 10/8 and that any other large provider was accepting it so wanted to verify. Wasn't it established that they did infact not leak it but just routed it inside their own network? This is not true. I am attached to 7018 and we saw 10/X routes. We are not ATT. bye, ken emery
Re: ATT carrying rfc1918 on the as7018 backbone?
On Thu, 22 Jan 2004, Brett Watson wrote: First, yes I know I should call ATT but I want to know if anyone else sees this problem: I have a customer that is multi-homed to ATT and WCOM. They accept default via BGP from both providers and announce a handful of prefixes to both providers. Given that they receive default, it's just the same as if they had a *static* default to both providers. The customer installed a network mapping tool today and suddenly discovered they were seeing RFC1918 addresses in the map (hundreds of them) that were *not* part of the customer's internal network. It turns out that from what we can tell, insightbb.com (an ATT sub or customer) is probably unintentionally leaking 10/8 and ATT is propogating that across their network.Since the customer defaults for any unknown destination, they're crossing the ATT network. If my customer had been taking full routing, with appropriate filters of course, they wouldn't be seeing this. But given that they are taking default, they see it. So I just wanted to see if anyone that is defaulting to ATT is seeing this same problem just to verify that what we're seeing is correct (for my customer's edification). Yes, I'm calling ATT now :) Yep, they are sending 10.X.X.X routes to customers. From several places actually, Level3, Comcast (multiple AS's), ATT, MediaOne, and AccessPoint. bye, ken emery
Re: ATT carrying rfc1918 on the as7018 backbone?
On Thu, 22 Jan 2004, Matthew S. Hallacy wrote: snip ATTBB (Now Comcast) uses ATT.net for connectivity, Comcast has to reach all their cable modems across the USA from their outsourced tech support centers, thus, att.net routes 10/8 across their network. Okay, that's fine. However why are there routes from Level3? Also I'm not Comcast so why am I seeing the routes? Also if Comcast needs this they should be paying for a tunnel over ATT network (like the rest of us would have to do). bye, ken emery
Re: ATT carrying rfc1918 on the as7018 backbone?
On Thu, 22 Jan 2004, Brett Watson wrote: The router at route-server.ip.att.net shows about 25 10.0.0.0/8 prefixes, most showing up over 4 weeks ago. Odd. I didn't see this when looking at att's looking glass via web browser. I was looking for some smaller prefixes though and didn't just look for 10/8 :-/ Btw, I was wrong in saying Level3 was one of the sources. They are announcing 8/8 which was just above the 10.X announcements. I was off by a line. Sorry if this caused any confusion. Btw, the announcements we are seeing are sized from /12 to /24. bye, ken emery
Re: .ORG Registrar ID List (was: Stupid .org registry code change)
On Mon, 22 Dec 2003, Mike Lewinski wrote:
Bruce Beckwith wrote:
You should deal with a registrar for this information, since that is one
of the services they can provide for you.
Right, but in a case where my client inherited a domain from their
predecessor, and has no idea who their registrar is, I seem to be in a
catch-22 This was my purpose in issuing a whois query to begin with-
to learn which registrar they need to contact to make DNS authority changes.
OTOH, if you are suggesting that I should contact *my* registrar of
choice to obtain this information... this seems more than a little
ridiculous (to me at least, and I suspect OpenSRS is not going to
appreciate getting a new support ticket every time I want to do a whois
to figure out what other registrar has a domain that my client doesn't
even intend to transfer to them).
Actually your registrar of choice should be able to easily get this
information. However if your registrar is just doing things to keep
prices as low as possible then they probably won't appreciate being
asked to do this sort of thing (there is a reason to use the more
expensive registrars).
Why should I {e-mail|call} to get what used to be available with a
simple whois query?
Is there a standard for a whois query? If not you are kind of
screwed. You have just been relying on things staying the same
and been lucky so far that they haven't changed much.
What have we gained by making this process even more
complicated? I have no beef with the use of Registrar IDs, I'm sure
there are benefits to using them. But I do think that they are a poor
substitute for what used to be human-readable information.
This I agree with. However for my .org domain and a couple of
others I work with (that are at different registrars) all have the
same outputs if you use whois -h whois.pir.org domainname.org.
Different registrars at the .com/.net level have different outputs
so I can't see where this would be a difficult problem.
bye,
ken emery
RE: Bandwidth Control Question
On Sat, 20 Dec 2003, Stephen J. Wilcox wrote: On Fri, 19 Dec 2003, ken emery wrote: On Fri, 19 Dec 2003, Roy wrote: Media converters are much cheaper than specialized FX cards like these. A 10Mbps converters are just $99 each and 100Mbps is $150. Yes, but you need external power for these and they aren't monitorable/configurable from any interface. Thus if one goes down and you can't physically see it you have no idea where the problem is until someone gets onsite. This is true of any physical fault, if your cable stops working you still have to go and physically take a look... But with something that is remotely monitorable (like a router) and that is multiply connected the odds are alot higher that you will be able to diagnose the problem. Also if the interface is part of the router there is no extra cabling power needed. This is a big plus IMHO. bye, ken emery bye, ken emery -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Stephen Sprunk Sent: Friday, December 19, 2003 10:13 AM To: Claydon, Tom Cc: North American Noise and Off-topic Gripes Subject: Re: Bandwidth Control Question Thus spake Claydon, Tom [EMAIL PROTECTED] Yep. There's plenty of fiber between the two buildings, so we may go that route. Anyone know if there's any easy way to limit bandwidth on the PA-POS-OC3 adapters? PA-POS-OC3MM$6000/card$38.71/Mbit PA-FE-FX$3200/card$32.00/Mbit PA-2FE-FX$5000/card$25.00/Mbit Why muck with SONET unless necessary? Sounds like another job for rate limiting to me... Yes. ! policy-map 6Mb-customer class class-default police 6144 ! interface foo service-policy input 6Mb-customer service-policy output 6Mb-customer ! S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: False information: CEO of Versign facts are wrong
On Fri, 17 Oct 2003, Mark Boolootian wrote: This factoid has been proven false multiple times, in multiple forums over the last year. Its incredible that a CEO of a company that claims DNS expertise wouldn't know this was false. One particular internet security company was PINGing the root servers, and some of the root server operators turned off ping. The root servers themselves were unaffected (except maybe one operated by the US Military). It might be a matter of interpretation. According to http://d.root-servers.org/october21.txt: 2.1. Some root name servers were unreachable from many parts of the global Internet due to congestion from the attack traffic delivered upstream/nearby. While all servers continued to answer all queries they received (due to successful overprovisioning of host resources), many valid queries were unable to reach some root name servers due to attack- related congestion effects, and thus went unanswered. While I'm not trying to act as Sclavos' apologist, I think you have to be careful about how you respond to this particular claim of his. You can't dismiss it out-of-hand. Misleading? Yes. Flat out false? You'd have to be more convincing. Can Sclavos prove that the same thing did not happen to Verisign's root servers? bye, ken emery
Re: [Fwd: [IP] VeriSign to revive redirect service]
On 16 Oct 2003, Paul Vixie wrote: Good writeup Paul. SNIP To change this: what else can we do to prevent this? Does the last BIND version truly break sitefinder? in my last conversation with a verisign executive, i learned that there is a widely held misconception that the last BIND patch truly breaks sitefinder, and now here you go proving it. the last BIND patch adds a feature, whose default is OFF, that can make non-delegation data from specified domains disappear (or in other cases, non-delegation data from non-specified tld's.) let me just emphasize that the default is OFF. BIND doesn't break sitefinder; nameserver adminstrators break sitefinder. be mindful of that difference! Paul, you've just bought into the Verisign propaganda here. The BIND modification does NOTHING to break Sitefinder. One can still go to http://sitefinder.verisign.com/ and use the web page without any interference from BIND. What the latest release does is to break the redirection of RCODE 3 to http://sitefinder.verisign.com/. It is just semantics, but there is a HUGE difference. Verisign can get people to start using the Sitefinder web site in any number of ways which don't affect other applications. These methods have been noted here and elsewhere (web browser plugins, advertising of the site, make it better than anything else and they will come, ...). Verisign's Sitefinder is NOT a TLD web site but they are trying to make it one. bye, ken emery p.s. I just went to sitefinder.verisign.com and it took forever to load. I assume that loads are down on this service so I can't understand why it would take so long to load the page. If this is the type of service Verisign is going to offer they will surely be inviting workarounds solely becuase things suck.
Re: Block all servers?
On Sat, 11 Oct 2003, Adam Selene wrote: Also what about folks who need to VPN in to their office (either via PPTP or IPSEC)? How would you take care of that situation? I use IPSEC and it works fine behind NAT. Yes, it does work, on a small scale. However what if your neighbor wants to IPSEC to the same place (say you work at the same place). If both of you are NAT'd from the same IP address trying to IPSEC to the same IP address? I don't believe things will work in this instance. bye, ken emery
Re: Block all servers?
On Sat, 11 Oct 2003, Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Alex Yurie v writes: Also what about folks who need to VPN in to their office (either via PPTP or IPSEC)? How would you take care of that situation? IPSEC works over NATs just fine. Not in the general case, no. See draft-aboba-nat-ipsec-04.txt if you can find a copy. This internet draft is available at: http://quimby.gnus.org/internet-drafts/draft-aboba-nat-ipsec-04.txt I can't figure out if anything happened with this draft (I'm guessing nothing went on). The draft expired on December 1, 2001. bye, ken emery
Re: Block all servers?
On Fri, 10 Oct 2003, Adam Selene wrote: IMHO, all consumer network access should be behind NAT. Unfortuantely there are enough protocols and applications which don't work well behind a NAT that deploying this on a large scale is not practical. Most gamers require incoming connections. These are people who willing to pay for bandwidth so attempting to put them in the nat only box will not work. Also what about folks who need to VPN in to their office (either via PPTP or IPSEC)? How would you take care of that situation? However, the real solutions is (and unfortunately to the detriment of many 3rd party software companies) for operating system companies such as Microsoft to realize a system level firewall is no longer something to be added on or configured later. Systems need to be shipped completely locked down (incoming *and* outgoing IP ports), and there should be an API for applications to request permission to access a particular port or listen on a particular port (invoking a user dialog). Unfortunately something like this would make the PC close to useless which is not the intent of the software provider. Thus you see everything open, security be damned. As for plug-in workgroup networking (the main reason why everything is open by default), when you create a Workgroup, it should require a key for that workgroup and enable shared-key IPSEC. And joe user will understand this because. Currently Windows 2000 can be configured to be extremely secure without any additional software. Unfortunately you must have a *lot* of clue to configure the Machine and IP security policies it provides. And there lies your problem (among other places) bye, ken emery
Re: More news coverage
On Wed, 8 Oct 2003, Howard C. Berkowitz wrote: Associated Press at http://www.boston.com/business/technology/articles/2003/10/08/experts_describe_site_finder_problems/ I am talking with the reporter, Ted Bridis. Associated Press reporters are under about as tough a deadline as TV, so it's a good fast first pass. I think the thing which needs to be gotten across to the general public (and the decision makers) is the SiteFinder service itself was NOT shut down. The redirection to the SiteFinder service was what was shut down. This was done because this redirection is believed to have adverse side effects. The way things are being painted it seems that the SiteFinder service was turned off and there is nothing further from the truth. bye, ken emery
Re: VeriSign SMTP reject server updated
On Sat, 20 Sep 2003, Matt Larson wrote: Folks, One piece of feedback we received multiple times after the addition of the wildcard A record to the .com/.net zones concerned snubby, our SMTP mail rejection server. This server was designed to be the most modest of SMTP implementations and supported only the most common sequence of SMTP commands. In response to this feedback, we have deployed an alternate SMTP implementation using Postfix that should address many of the concerns we've heard. Like snubby, this server rejects any mail sent to it (by returning 550 in response to any number of RCPT TO commands). We would like to state for the record that the only purpose of this server is to reject mail immediately to avoid its remaining in MTA queues throughout the Internet. We are specifically not retaining, nor do we have any intention to retain, any email addresses from these SMTP transactions. In fact, to achieve sufficient performance, all logging has been disabled. We are interested in feedback on the best way within the SMTP protocol to definitively reject mail at these servers. One alternate option we are considering is rejecting the SMTP transaction by returning a 554 response code as described in Section 3.1 of RFC 2821. Our concern is if this response effectively causes most SMTP servers to bounce the message, which is the desired reaction. We are researching common SMTP servers' handling of this response code; at least one popular server appears to requeue mail after receiving 554. Another option is remaining with the more standard SMTP sequence (returning 250 in response to HELO/EHLO), but then returning 550 in response to MAIL FROM as well as RCPT TO. I would welcome feedback on these options sent to me privately or the list; I will summarize the former. Matt, I think you haven't gotten it. I'm getting the message from you that the changes made to the com and net gTLD's are fait accompli. From the message above it sounds like by changing your smtp server everything will be perfect and back to normal on the internet. The problem here is by adding wildcard records Verisign has broken lots of software (the internet is NOT just the web no matter what Verisign would like one to believe). Many spam algorithms have relied on the fact that nonexitent domain names are one of the ways (and a very effective one at that) to filter spam. Other registrars do and nslookup on a domain name when attempting to register and if this comes back positive then the domain is considered taken. Is Verisign expecting everyone else to modify software which has been working for years (based on what have been valid assumptions for well over a decade)? This will cost millions (if not billions) of dollars. As those in the spam world would say, the collateral damage is very high for this type of change. Is Verisign going to hold the internet hostage to its whims? So let us know why exactly you should be able to redirect any protocol you wish to your IP addresses if someone mistypes a domain. I look forward to your response. bye, ken emery
Re: VeriSign SMTP reject server updated
On Sat, 20 Sep 2003, neal rauhauser wrote: Oh come on people, this guy *implements* stuff. Here he is on the list describing how he has implemented something to alleviate the problems caused by PHBs at Verisign. He is a representative of Verisign and asked for feedback. He has gotten some. I honestly think that the person who made the decision to implement the A records thought the internet was only web and thus everything would be just great and Verisign would take in all sorts of advertising money and nothing else would happen. ISC bind mods, ICANN displeasure, and other sources of pressure will either remove this issue or make it irrelevant. Doubtful, the dollar number I heard was $100 million/year. Verisign won't let a bind mod get in their way with that much money at stake. They will do everything in their power to keep this in place. Rather than bashing someone who is doing something positive we should see if we can paypal him $$$ for a box of tacks so he can mine the chairs of the tack head marketing weasels who decided this would be a good idea ... I wrote a response to Matt (it went to the list). I used the directives Verisign and you a bit interchanably. They both were to mean the same thing, Verisign the company, not Matt Larson the person. I think the other responses I've seen so far were much the same. I'm hoping Matt doesn't take any of this personally. bye, ken emery Matthew Kaufman wrote: One piece of feedback we received multiple times after the addition of the wildcard A record to the .com/.net zones concerned snubby, our SMTP mail rejection server. Did you miss the other pieces of feedback about how wildcard records in .com and .net are simply a bad idea for numerous reasons? We would like to state for the record that the only purpose of this server is to reject mail immediately to avoid its remaining in MTA queues throughout the Internet. We are specifically not retaining, nor do we have any intention to retain, any email addresses from these SMTP transactions. Right. We can't trust you to do the right thing with regard to the wildcards themselves, so now we have to trust you when you tell us what your SMTP server does. Why should we trust you, again? I would welcome feedback on these options sent to me privately or the list; I will summarize the former. I'll take the list, even though I'm sure it'll get beaten to death by the time I check my mailbox again. Matthew Kaufman [EMAIL PROTECTED] Ps. Are you planning on operating servers which reject, with proper status codes, every other common service that might be found at an Internet address? -- mailto:[EMAIL PROTECTED] phone:402-301-9555 After all that I've been through, you're the only one who matters, you never left me in the dark here on my own - Widespread Panic
Re: Heads up -- potential problems in 3.7, too? [Fwd: OpenSSH Security Advisory: buffer.adv]
On Tue, 16 Sep 2003 [EMAIL PROTECTED] wrote:
I hope you mean OpenSSH 3.7p1 ?
No, he means 3.7.1. There was another release today.
bye,
ken emery
On Tue, 16 Sep 2003, Alex Lambert wrote:
3.7.1 was just released.
Two patches for similar issues in a very short timeframe. Who do they
think they are -- Microsoft? grin
apl
Original Message
Subject: OpenSSH Security Advisory: buffer.adv
Date: Wed, 17 Sep 2003 01:13:30 +0200
From: Markus Friedl [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
This is the 2nd revision of the Advisory.
This document can be found at: http://www.openssh.com/txt/buffer.adv
1. Versions affected:
All versions of OpenSSH's sshd prior to 3.7.1 contain buffer
management errors. It is uncertain whether these errors are
potentially exploitable, however, we prefer to see bugs
fixed proactively.
Other implementations sharing common origin may also have
these issues.
2. Solution:
Upgrade to OpenSSH 3.7.1 or apply the following patch.
===
Appendix A: patch for OpenSSH 3.6.1 and earlier
Index: buffer.c
===
RCS file: /cvs/src/usr.bin/ssh/buffer.c,v
retrieving revision 1.16
retrieving revision 1.18
diff -u -r1.16 -r1.18
--- buffer.c26 Jun 2002 08:54:18 - 1.16
+++ buffer.c16 Sep 2003 21:02:39 - 1.18
@@ -23,8 +23,11 @@
void
buffer_init(Buffer *buffer)
{
- buffer-alloc = 4096;
- buffer-buf = xmalloc(buffer-alloc);
+ const u_int len = 4096;
+
+ buffer-alloc = 0;
+ buffer-buf = xmalloc(len);
+ buffer-alloc = len;
buffer-offset = 0;
buffer-end = 0;
}
@@ -34,8 +37,10 @@
void
buffer_free(Buffer *buffer)
{
- memset(buffer-buf, 0, buffer-alloc);
- xfree(buffer-buf);
+ if (buffer-alloc 0) {
+ memset(buffer-buf, 0, buffer-alloc);
+ xfree(buffer-buf);
+ }
}
/*
@@ -69,6 +74,7 @@
void *
buffer_append_space(Buffer *buffer, u_int len)
{
+ u_int newlen;
void *p;
if (len 0x10)
@@ -98,11 +104,13 @@
goto restart;
}
/* Increase the size of the buffer and retry. */
- buffer-alloc += len + 32768;
- if (buffer-alloc 0xa0)
+
+ newlen = buffer-alloc + len + 32768;
+ if (newlen 0xa0)
fatal(buffer_append_space: alloc %u not supported,
- buffer-alloc);
- buffer-buf = xrealloc(buffer-buf, buffer-alloc);
+ newlen);
+ buffer-buf = xrealloc(buffer-buf, newlen);
+ buffer-alloc = newlen;
goto restart;
/* NOTREACHED */
}
Index: channels.c
===
RCS file: /cvs/src/usr.bin/ssh/channels.c,v
retrieving revision 1.194
retrieving revision 1.195
diff -u -r1.194 -r1.195
--- channels.c 29 Aug 2003 10:04:36 - 1.194
+++ channels.c 16 Sep 2003 21:02:40 - 1.195
@@ -228,12 +228,13 @@
if (found == -1) {
/* There are no free slots. Take last+1 slot and expand the array. */
found = channels_alloc;
- channels_alloc += 10;
if (channels_alloc 1)
fatal(channel_new: internal error: channels_alloc %d
too big., channels_alloc);
+ channels = xrealloc(channels,
+ (channels_alloc + 10) * sizeof(Channel *));
+ channels_alloc += 10;
debug2(channel: expanding %d, channels_alloc);
- channels = xrealloc(channels, channels_alloc * sizeof(Channel *));
for (i = found; i channels_alloc; i++)
channels[i] = NULL;
}
===
Appendix B: patch for OpenSSH 3.7
Index: buffer.c
===
RCS file: /cvs/src/usr.bin/ssh/buffer.c,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- buffer.c16 Sep 2003 03:03:47 - 1.17
+++ buffer.c16 Sep 2003 21:02:39 - 1.18
@@ -23,8 +23,11 @@
void
buffer_init(Buffer *buffer)
{
- buffer-alloc = 4096;
- buffer-buf = xmalloc(buffer-alloc);
+ const u_int len = 4096;
+
+ buffer-alloc = 0;
+ buffer-buf = xmalloc(len);
+ buffer-alloc = len;
buffer-offset = 0;
buffer-end = 0;
}
@@ -34,8 +37,10 @@
void
buffer_free(Buffer *buffer)
{
- memset(buffer-buf, 0, buffer-alloc);
- xfree(buffer-buf);
+ if (buffer-alloc 0) {
+ memset(buffer-buf, 0, buffer-alloc);
+ xfree(buffer-buf);
+ }
}
/*
Index: channels.c
RE: What *are* they smoking?
On Tue, 16 Sep 2003, Jeroen Massar wrote: -BEGIN PGP SIGNED MESSAGE- Tim Wilde wrote: On Tue, 16 Sep 2003, Niels Bakker wrote: A wildcard A record in the net TLD. $ host does.really-not-exist.net does.really-not-exist.net has address 64.94.110.11 $ host 64.94.110.11 11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com It even responds on port 25 (says 550 on every RCPT TO). Gah. Even worse of this is that you can't verify domain names under .net any more for 'existence' as every .net domain suddenly has a A record and then can be used for spamming... From: Spammer [EMAIL PROTECTED] To: You [EMAIL PROTECTED] Thank you Verisign! Now we need to check for existence of an MX and then just break a couple of RFC's in the process :( What about if the IP address returned by the DNS query is the same one as does.really-not-exist.net then the spam is returned to the owner of the IP address? In this case Versign. I think this is already done by some automated spam reporting tools. If AOL does it Verisign will probably get crushed by the load (if one is having a spam war with AOL's mail servers AOL will always win). It's Verisign's return shot at the web browser couldn't find this page searches. Doesn't seem to have much by way of advertising yet, but I'm sure that'll change. I heard about this coming from somewhere last week, though I don't recall where. Probably Wired or the WSJ. Verisign wants the revenue that all those typos are generating. It's just the next shot in the eyeball war. Who said the internet wasn't commercial again ? Thank you goverment of the United States of America for allowing such money hungry organisations to abuse one of the original tld's. Wasn't .net meant for *networks* ? aka ISP backbone infrastructure and not for commercials? That has been going on for several years now (unfortunately). (And I thought that domain reselling was a yucky business) Yep, but it can be profitable. I'm just waiting for someone to put out a typo in a large press release and then sue Verisign for stealing all the traffic. According to the article in the link posted from cbronline.com this has been done by NeuStar who runs the .biz and .us domain registries. The company which runs this service for NeuStar claims to be able to differentiate between http and other requests. I'm still waiting to see how they do this as you can't tell from a DNS request alone. bye, ken emery
Re: User negligence?
On Sun, 27 Jul 2003, Stephen Sprunk wrote: That's not even the dumbest part. You can reset your password at most banks, insurance companies, stores, airlines, etc. by claiming you forgot it; they'll happily reset it to your mother's maiden name, SSN, or some other publicly-available datum. NOTE: I've had over $42,000 stolen from bank accounts via the internet. Take that into account when you read this... First of all security of the physical and network bank web sites may very well be up to snuff. However when you combine with the customer service side of things for the whole package BANK SECURITY IS AN ABSOLUTE JOKE! At one bank I was at someone called up claiming to be me and setup my web account and wired themselves $9,500 three times over a two day period. They even called the bank back asking what was taking so long and why the money wasn't in their account yet. When I found out about this a month later (I had no reason to check the website since I didn't use it) the bank was able to reverse two of the tranfers and ate the other one (noone ever said thieves were smart, they never moved most of the money out of the destination account). During the conversations with the bank I asked that the account be disabled and never enabled again and to have this request noted. Well about 8 months later someone called in claiming to be me and got the account reenabled. They had a bank check made out to themselves for about $13,500 and sent via postal mail. Fortunately they got caught cashing the check in AZ and are now in jail awaiting trial. That however is not the end of things. I haven't had any more money stolen, but at another bank, which I have been at for well over 10 years thus predating any web site, they automatically setup web accounts with a default password (last four digits of your SSN). When I heard this I said to my self oh %^*! I asked to have the web account disabled and was told this could not be done. So I immediately went back to my computer and changed the password. Fortunately noone has done anything with that account. Basically while the network security may be there that is only part of the package and the rest of the package is not up to snuff. The big problem in my eyes is that physical presense is no longer necessary so it is next to impossible to catch these thieves (unless they do stupid things like the ones who stole from me). A sophisticated criminal will probably be able to get away with millions of dollars in a very short period of time and be able to vanish without a trace. I'm not sure what needs to be done, but the security as now implemented is not even close to enough IMHO. Networkwise (to bring this back on topic) I'm not sure there is really much that can be done. bye, ken emery
