Re: Upcoming change to SOA values in .com and .net zones
On 7 Jan 2004 23:02 UTC Frank Louwers <[EMAIL PROTECTED]> wrote: | > generated twice per day, so NN is usually either 00 or 01.) | > January 1970.) For example, a zone published on 9 February 2004 might | > have serial number "1076370400". The .com and .net zones will still | > be generated twice per day, but this serial number format change is in | > preparation for potentially more frequent updates to these zones. | stuid question Yup! | but isn't 2004010101 (today) > 1076370400 (9 Feb 2004)? Nope! >> The new format will be the UTC time at the moment of zone generation >> encoded as the number of seconds since the UNIX epoch. ^ ... and not as MMDDHHMMSS or any contracted version thereof! -- Richard
Re: Wired mag article on spammers playing traceroute games with trojaned boxes
On Thu, 9 Oct 2003 12:01:35 -0400 "McBurnett, Jim" <[EMAIL PROTECTED]> wrote: | I think even if we get all the ones for this domain name today, | assuming we can muster even man hours to get it today, another | 5000 will be added tomorrow. And looking at my list We have US | (a very small ISP and a large ISP) RIPE, and LACNIC. This malware is not new, but is only just becoming widely visible. It succeeds solely because of the "Dynamic-DYS" (real-time updating) functionality built into the dot-biz registry. Certainly it can be killed, but the techniques to achieve that are better discussed OFF this list - for both AUP and other valid reasons. As soon as this exploit is killed, no doubt another, similar, exploit would follow. We therefore need a more generic solution to the issue. | This not only affects this instance but global security as a whole. | Just a few days ago, Cisco was taken offline by a large # of Zombies, | I am willing to say that those are potentially some of the same | compromised systems. Empirical evidence would seem to support your view. Even where they are not the same zombies, networks that allow this type of zombie to remain in place are just as likely to allow DDoS zombies to continue undisturbed. The problem is that many ISPs filter all issues of this nature through their abuse teams, rather than sending them directly to their security specialists. Most abuse teams have neither the time nor experience to investigate, and this particular trojan has been written to make it too easy for abuse teams to dismiss reports of its activity, and then to justify taking no action - that is exactly what the writers of the malware intended to happen. A step change in attitude from providers who offer 24/7-on connectivity is what is needed now, and agreement to separate all network security issues from their abuse desk procedures should be number one priority. -- Richard Cox
Re: ftp.cisco.com broken ?
On 7 Oct 2003 17:39 UTC Ezequiel Carson <[EMAIL PROTECTED]> wrote: | hi, can you resolve ftp.cisco.com? | | [EMAIL PROTECTED] /]# ping ftp.cisco.com | ping: unknown host ftp.cisco.com | [EMAIL PROTECTED] /]# | | something is wrong here I can both resolve and reach it from opposite ends of the planet ... Trace ftp.cisco.com (198.133.219.27) ... 1 192.168.34.2 1ms FastEth8-1-0.sb1.optus.net.au 2 61.88.178.81ms gi3-0.ig6.optus.net.au 3 203.208.148.101 232ms 4 203.208.172.45 220ms p6-1.plapx-cr1.ix.singtel.com 5 203.208.168.225 231ms 6 203.208.168.218 231ms 7 63.169.235.133 164ms leg-63-169-235-133-CHI.sprinthome.com 8 144.232.20.125 213ms sl-bb20-ana-4-3.sprintlink.net 9 144.232.1.134165ms sl-bb23-ana-9-0.sprintlink.net 10 144.232.20.159 166ms sl-bb25-sj-9-0.sprintlink.net 11 144.232.3.134166ms sl-gw11-sj-10-0.sprintlink.net 12 144.228.44.14167ms sl-ciscopsn2-11-0-0.sprintlink.net 13 128.107.239.89 175ms sjce-dirty-gw1.cisco.com 14 128.107.239.102 175ms sjck-sdf-ciod-gw2.cisco.com 15 198.133.219.27 175ms ftp-sj.cisco.com Trace ftp.cisco.com (64.102.255.95) ... 1 217.146.111.97 0ms gateway.mandarin.com 2 213.123.101.8920ms 3 217.146.102.237 20ms 4 213.200.77.93 50ms 5 213.200.81.74 30ms 6 213.206.159.5 40ms sl-gw10-lon-5-1.sprintlink.net 7 213.206.128.4530ms sl-bb21-lon-8-0.sprintlink.net 8 144.232.19.69150ms sl-bb21-tuk-10-0.sprintlink.net 9 144.232.20.13290ms sl-bb20-tuk-15-0.sprintlink.net 10 144.232.20.122 120ms sl-bb21-rly-14-3.sprintlink.net 11 144.232.14.134 160ms sl-bb23-rly-11-0.sprintlink.net 12 144.232.14.46130ms sl-gw20-rly-10-0.sprintlink.net 13 144.232.244.210 130ms sl-ciscopsn2-12-0.sprintlink.net 14 64.102.254.194 100ms rtp7-dirty-gw1.cisco.com 15 64.102.254.205 120ms rtp5-ciod-gw2.cisco.com 16 64.102.255.95110ms ftp-rtp.cisco.com -- Richard
Re: Fun new policy at AOL
On 28 Aug 2003 16:07 UTC Matthew Crocker <[EMAIL PROTECTED]> wrote: | AOL for example could require ISPs to meet certain criteria before | they are allowed direct connections. ISPs would need to contact AOL, | provide valid contact into and accept some sort of AUP (I shall not | spam AOL...) and then be allowed to connect from their IPs. AOL could | kick that mail server off later if they determine they are spamming. If you replace "AOL" with some body or set of bodies, unrelated to (but trusted by) large numbers of networks, then you have what I regard as the only ultimately workable solution to the present situation. The devil is in the details - finding and trusting such bodies: however it may be that they are already amongst us but under a different name! -- Richard Cox %% HELO - the first word of every Email transaction - is in Welsh! %%
Re: Complaint of the week: Ebay abuse mail (slightly OT)
Valdis Kletnieks <[EMAIL PROTECTED]> wrote: > 1) What *immediate* benefits do you get if you are among the first to > deploy? (For instance, note that you can't stop accepting "plain old > SMTP" till everybody else deploys). The immediate benefit (as sender) is that you reduce the (now ever-increasing) risk of your mail being rejected by filtration processes and will be trusted on arrival; the benefit for the recipient is of course less junk! However you CAN stop accepting "plain old SMTP" right away, because you can delegate that to a filtration service that hosts your old-style MX, applies ever-increasingly stringent filtration rules, and then forwards to you using the new protocol. Several such filtrations services may well appear when the time is right. > 2) Who bears the implementation cost when a site deploys, and who gets >the benefit? (If it costs *me* to deploy, but *you* get the benefit, >why do I want to do this?) Both parties get benefits which seriously outweigh the costs! > 3) What percentage of sites have to deploy before it makes a real > difference, and what incremental benefit is there to deploying before that? To some extent the concept is already here, and deployed, whether using in-house filters or remote-MX, to subject the unauthenticated mail - which of course is currently ALL the mail - to appropriate filtering. > (For any given scheme that doesn't fly unless 90% or more of sites do it, > explain how you bootstrap it). That is a very valid point that most people don't address. I define any new scheme as unworkable unless someone can describe the present, albeit unsatisfactory, arrangements that it offers to replace as a "special case" of the new scheme for which there is clearly-defined correct handling. > 4) Does the protocol still keep providing benefit if everybody deploys it? That depends entirely on the contactual relationships that may exist between mail-exchanging sites. Just implementing an authenticating protocol on its own will NOT help. There will be a prima-facie need for a selection of "trust-authorities" who specify what is acceptable for their trusted-senders to send. Recipients then get to choose which criteria are closest to their requirements (including whitelisting if needed on a per-site basis). > (This is a common problem with SpamAssassin-like content filters - if most > sites filter phrase "xyz", spammers will learn to not use that phrase). That goes for any precautions taken - not just content filters. That is WHY the contractual relationships are absolutely essential for any new scheme. And there, too, lies the bulk of the work needed - the technical issues do not place any great demands on the networking community. > If you have a *serious* proposal that actually passes all 4 questions > (in other words, it provides immediate benefit to early adopters, and > still works when everybody does it), bring it on over to '[EMAIL PROTECTED]'. Heh. The noise-to-signal level *there* is far worse than in NANOG - by at least 12dB last time I looked ;-) -- Richard Cox RC1500-RIPE
Re: National Do Not Call Registry has opened
On Tue, 1 Jul 2003 11:28:05 +0200 "Petri Helenius" <[EMAIL PROTECTED]> wrote: | bulk buying international minutes to non-regulated destinations costs | you less than a consumer pays for interstate call within the US. On which basis inbound telemarketing calls from ostensibly non-regulated sources may be expected to start real soon now. It is already happening with unsolicited faxes, as some people are painfully aware. This comment is not to be taken as a view on whether such calls would, or would not, be caught by the new legislation. It may however be taken as a view as to whether the telemarketers think they can get away with it! -- Richard D G Cox Mandarin Technology
Re: Spam from weird IP 118.189.136.119
On Mon, 16 Jun 2003 15:47 (UT), [EMAIL PROTECTED] wrote: | I've never heard of the NNFMP protocol It's the latest spammer exploit the "Network Nonsense - Fools Most People" exploit. You've not been hit by that one yet, then? On Mon, 16 Jun 2003 17:47 (UT), Wayne Tucker <[EMAIL PROTECTED]> wrote: | I have run into a considerable number of these that include headers | suggesting that they were relayed through my server, but I have verified | my logs, and the messages never even touched any of my machines. But precisely which logs are you looking at? The SMTP logs from your mail server or the machine's IP connection log? | It seems that one of the new tricks is to throw some BS headers in there | before relaying the message, just to throw a monkey wrench in the works. That is one of the older tricks in the book. The latest revision is to throw some _matching_ headers in there so that it looks entirely genuine. If you have a trojan executable on a server as well as an "authorised" mail server then any mail sent by the trojan will NOT appear in the logs of the SMTP server, but WILL appear on the next hop as coming from your server and the only way to tell the difference is by examining the connecting port as seen coming from your server by the machine at next hop. -- Richard D G Cox
Re: Spam from weird IP 118.189.136.119
On Mon, 16 Jun 2003 17:33:11 +0200, "Pascal Gloor" <[EMAIL PROTECTED]> wrote: | Getting SPAM from 118.189.136.119 relayed by rr.com ? | | this network is not allocated, nor announced. I have been looking everywhere | to find if it has been announced (historical bgp update databases, like RIS | RIPE / CIDR REPORT / etc..)... I didnt found anything this probably mean | rr.com is routing that network internaly. This is very likely to be a known exploit I have been tracking. In all the cases which we have so far confirmed, the spam was not relayed, but proxied by a trojan executable which is able to mimic a "previous" header with such a degree of accuracy that it is indistinguishable from the genuine article! | If there is any rr.com guy around. Could you please check this? Our advice would be that the server-that-connected-to-you needs to be taken offline by the security people at its site (which you say is RoadRunner) and they should have ALL its disk(s) imaged for forensic analysis purposes. Our experience is that sites hit by this exploit will do basic checks on the server and claim it is uncompromised and "cannot possibly be sending that spam". Such a claim would be entirely incorrect. You would need to persuade them that something is wrong, which is difficult at the best of times. RoadRunner being involved in this case suggests this may *not* be the "best of times". -- Richard Cox
