Re: FC: Email a RoadRunner address, get scanned by their securitysystem]
I only find it humorous that a majority of the network probes against my network come from RoadRunner cable modems as it is, yet they want to add to it by having their own server run a probe... Not that I email many RR customers as it is directly through my mail servers... I also enjoy the ironic humor in the fact my home network is on statically assigned DSL IP space that I hold forward and reverse DNS control for but by their own statements I could not opt-out even though it is SWIP'd to me but is a DSL allocation... No worries the only machines on my network that would send outgoing email are behind a NAT that does port forwarding so even if they connect back on port 80 from the IP that connects to port 25 on their server doesn't mean they're talking back to even the same machine here... In all fairness though looking at the top 15 source addresses my IDS has pick'd up lately... 9 of the 15 are from my own providers space and they don't even react to reports... 90% of the hits are still CodeRed no less... Jeremy On Fri, Mar 14, 2003 at 10:27:03PM -0600, Jack Bates wrote: > > Sending email to many servers means that your mail server will be probed for > open proxies and open relays. It's only seriously taboo when it leaves the > actual connecting server to scan the rest of the network. This is why I > posted previously about a centralized system so that we can limit these > probes. In the case of RoadRunner, it is only inappropriate because RR > themselves complains and throughs a fit about being probed, and yet they > probe others. > > -Jack >
* * * SECURITY UPDATE * * * MRLG-4.2.4 Released * * * (fwd)
Forwarded by request.
-- Forwarded Message --
* * * SECURITY UPDATE FOR MULTI-ROUTER LOOKING GLASS * * *
A vulnerability has been discovered by the EnterZone staff in Multi-Router
Looking Glass versions 4.2.2 and 4.2.3.
Vulnerability:
If the MRLG admin has specified "$::output_before_menu = 1;" in mrlg.conf,
remote users are able execute MRLG commands on password (MRLG
password) protected routers that have been configured. This vulnerability
does not effect users who have not specified "$::output_before_menu =
1;" in mrlg.conf or MRLG versions prior to 4.2.2.
Fix:
Upgrade to MRLG-4.2.4, available for immediate download at:
ftp://ftp.enterzone.net/looking-glass/CURRENT/
Alternately, users running MRLG-4.2.3 may patch their MRLG to version
4.2.4 with the following patch:
*** index.cgi Wed Nov 27 01:23:57 2002
--- index.cgi.new Fri Mar 14 23:11:16 2003
*** no warnings "once";
*** 8,10
! $::Version='4.2.3 Beta (IPv6)';
--- 8,10
! $::Version='4.2.4 Beta (IPv6)';
*** set_router();
*** 150,154
--- 150,162
+ if ($::Form{'pass1'} eq $::Routers{$::Form{'router'}}{'pass'})
+ {
if ($::output_before_menu)
{
+ ## Set up which command is to be executed (and then execute it!)
set_command();
+ }
+ }
+ else
+ {
+ print "INVALID PASSWORD!";
}
-- End Forwarded Message --
Re: [Fwd: FC: Email a RoadRunner address, get scanned by their
From: <[EMAIL PROTECTED]> > > I suspect we've gotten to the point now that there are more open proxies > than open relays on the net, and it seems the proxies are more heavily > abused. > Perhaps it is because trojans and worms aren't setup to install open relays but to install open proxies. Proxies also have the advantage of hiding the original sender. I suspect that the next thing we will see is open proxies abused and then all traces wiped out by self protecting worms. -Jack
Re: [Fwd: FC: Email a RoadRunner address, get scanned by their
On Fri, 14 Mar 2003, Jeff Kell wrote: > > Basically, RoadRunner tried to spam themselves using my server. I mailed > > [EMAIL PROTECTED] about this, and received a canned response, enclosed. > > > > Under their logic, I feel entitled to poke and prod their customers, just > > to make sure they don't spam me. Is that fair? I promise to provide an > > opt-out if anyone complains. > > Oh no, they'll bitch, at great length. This was recently discussed on > SPAM-L ( http://peach.ease.lsoft.com/scripts/wa.exe?LIST=SPAM-L ). Actually, if you go a few rounds with Mr. Herrick of rr.com, and explain that you want to do the same sort of testing under the same ground rules as security.rr.com, I think you'll find that he will not object. It is quite ironic (perhaps a sign of how bad the problem of spam on the internet has gotten) that rr.com has decided to emulate those that they have attacked in the past. I suspect we've gotten to the point now that there are more open proxies than open relays on the net, and it seems the proxies are more heavily abused. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: [Fwd: FC: Email a RoadRunner address, get scanned by their securitysystem]
--On Friday, March 14, 2003 09:32:09 PM -0500 William Allen Simpson <[EMAIL PROTECTED]> wrote: After sending an email to a friend at a RoadRunner address, I see this in my web access log: 24.30.199.228 - - [13/Mar/2003:15:11:25 -0500] "CONNECT security.rr.com:25 HTTP/1.0" 404 535 "" "" spam-l is over there -->
Re: [Fwd: FC: Email a RoadRunner address, get scanned by their
From: Gunnar Hellekson <[EMAIL PROTECTED]> Basically, RoadRunner tried to spam themselves using my server. I mailed [EMAIL PROTECTED] about this, and received a canned response, enclosed. Under their logic, I feel entitled to poke and prod their customers, just to make sure they don't spam me. Is that fair? I promise to provide an opt-out if anyone complains. Oh no, they'll bitch, at great length. This was recently discussed on SPAM-L ( http://peach.ease.lsoft.com/scripts/wa.exe?LIST=SPAM-L ). Jeff
Re: FC: Email a RoadRunner address, get scanned by their securitysystem]
From: "William Allen Simpson > After sending an email to a friend at a RoadRunner address, I see this in > my web access log: > > 24.30.199.228 - - [13/Mar/2003:15:11:25 -0500] "CONNECT security.rr.com:25 > HTTP/1.0" 404 535 "" "" > > Basically, RoadRunner tried to spam themselves using my server. I mailed > [EMAIL PROTECTED] about this, and received a canned response, enclosed. It's a > humble response, but woefully inadequate. Have anti-spam measures come to > this? This seems like an ill-considered compromise between privacy and > anti-spam efforts. A blunt instrument that betrays less-than-careful > thinking. The opt-out option, which was revealed only after my complaint, > is even more obnoxious. Sending email to many servers means that your mail server will be probed for open proxies and open relays. It's only seriously taboo when it leaves the actual connecting server to scan the rest of the network. This is why I posted previously about a centralized system so that we can limit these probes. In the case of RoadRunner, it is only inappropriate because RR themselves complains and throughs a fit about being probed, and yet they probe others. -Jack
[Fwd: FC: Email a RoadRunner address, get scanned by their securitysystem]
Original Message Subject: FC: Email a RoadRunner address, get scanned by their securitysystem Date: Fri, 14 Mar 2003 15:25:46 -0500 From: Declan McCullagh <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] --- Date: Fri, 14 Mar 2003 15:22:24 -0500 Subject: RoadRunner Automated Portscans From: Gunnar Hellekson <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] After sending an email to a friend at a RoadRunner address, I see this in my web access log: 24.30.199.228 - - [13/Mar/2003:15:11:25 -0500] "CONNECT security.rr.com:25 HTTP/1.0" 404 535 "" "" Basically, RoadRunner tried to spam themselves using my server. I mailed [EMAIL PROTECTED] about this, and received a canned response, enclosed. It's a humble response, but woefully inadequate. Have anti-spam measures come to this? This seems like an ill-considered compromise between privacy and anti-spam efforts. A blunt instrument that betrays less-than-careful thinking. The opt-out option, which was revealed only after my complaint, is even more obnoxious. Under their logic, I feel entitled to poke and prod their customers, just to make sure they don't spam me. Is that fair? I promise to provide an opt-out if anyone complains. I'm curious whether this preemptive measure is effective at all. -Gunnar >From: "Road Runner Security \[DSR\]" <[EMAIL PROTECTED]> >Date: Fri Mar 14, 2003 2:05:12 PM America/New_York >Subject: Re: Port scans? > >Hello, > >The securityscan.sec.rr.com machine is a Road Runner Security resource that >is used as a tool to assist us in determining if machines being used to >send us mail may be abused from outside sources, allowing them to be used >to spam our customers and role accounts. We fully understand your concerns >surrounding the probing of your machine. This issue has been raised >internally and we hope this email helps you better understand our process. > >The intention of this process is truly not meant to be a "big brother" >system, but we understand that some may view it as such. Our ultimate goal, >however, is to protect our network, our customers, and our role accounts. > >Road Runner has begin the REACTIVE testing of IP addresses which connect >to its inbound SMTP gateways. If your machine connects to ours to send >email, we reserve the absolute right to perform SMTP relay and open proxy >server tests upon the connecting IP address to ensure that the machine at >that IP address cannot be abused for malicious > purposes. > >These scans are done once per week per IP, via an automated process, and >only on those servers that have sent our subscriber base mail. The only >way for these tests to occur is if an IP address connects to our inbound >SMTP gateway. If found to be an open proxy or smtp relay, the IP address >will be blocked at our mail gateway borders with one of the following >error messages: > >ERROR:5.7.1:550 Mail Refused - See >http://security.rr.com/mail_blocks.htm#proxy >ERROR:5.7.1:550 Mail Refused - See >http://security.rr.com/mail_blocks.htm#relay > >We understand that some entities may not wish to be scanned as part of this >automated process. If you do not wish to be tested by Road Runner, there >are two ways to accomplish this: > >1. Send an e-mail to '[EMAIL PROTECTED]' with the IP address that >you do not wish to be tested. Please note that if you are not the >designated contact for your IP address range (for example, if you are on a >cable modem, DSL, or dialup range), we will be unable to fulfill your >request for addition or removal. >2. Do not connect to our inbound SMTP servers. Again, this test is only >conducted on servers that connect to our servers. > >If you have any further questions, you can visit http://security.rr.com or >contact Road Runner Security via e-mail at '[EMAIL PROTECTED]' > >Regards, >Road Runner Security - POLITECH -- Declan McCullagh's politics and technology mailing list You may redistribute this message freely if you include this notice. To subscribe to Politech: http://www.politechbot.com/info/subscribe.html This message is archived at http://www.politechbot.com/ Like Politech? Make a donation here: http://www.politechbot.com/donate/ - Declan McCullagh's photographs are at http://www.mccullagh.org/ -
[Q] Stable Service Provider IOS Version?
nanog: I have to upgrade some 7513 routers running Service Provder IOS. I'd like to know what code have people been using that has proved stable as well as versions to stay away from. Thanks Matt __ http://www.invision.net/ ___ Matthew E. Martini, PEInVision.com, Inc. (631) 543-1000 x104 Chief Technology Officer [EMAIL PROTECTED](631) 864-8896 Fax ___pgp_
Re: 69/8...this sucks -- Centralizing filtering..
[ apologies for the long post ] On 2003-03-11 19:57:04 +, [EMAIL PROTECTED] wrote: > > Also, on a side rant hereWhy do all the RIR's have to give out > whois data in different, incompatible, referal-breaking formats? The reason for the different formats is partly historical, and partially a result of the fundamental differences between the RIR's. The historical reason is that each RIR has a different origin, and the databases and Whois software comes from that origin. The RIPE NCC started with nothing, evolved to RIPE-181, then RPSL, and is now moving to RPSLng + extensions. APNIC adopted RIPE NCC software, and is very nearly compatible. ARIN's database was inherited from the InterNIC, and has since evolved into a new, organisation-based model. I believe LACNIC's database is inherited from the Brazil domain name registry, so it uses that format (this is the one I am least familiar with - so I may be in error). The formats remain different because the RIR's have evolved their databases to solve problems that are most important in their regions. For instance, ARIN has chosen a model that reflects registration in a straightforward way, whereas RPSL is useful for operators wanting to document policy. > The next step in my work once my ping sweep is complete (looks like > that'll be today) is going to be to take a list of what looks like > it'll be ~1000 IPs and generate a list of the unique networks that > are broken. To do this, it'd be nice if there were some key I could > get from whois, store in a column, select a unique set from, then > reuse to lookup POCs from whois, and send off the emails. > > registro.br and LACNIC entries start with inetnum: using what I'll > call brief CIDR, i.e. > inetnum: 200.198.128/19 > > APNIC and RIPE entries start with inetnum:, but use range format. > i.e. > inetnum: 203.145.160.0 - 203.145.191.255 > > ARIN entries include fields like > NetRange: 128.63.0.0 - 128.63.255.255 > CIDR: 128.63.0.0/16 > > The APNIC and RIPE NetRange/inetnum fields are easy enough to deal > with, but send a whois request for 200.198.128/19 to whois.arin.net > and you get "No match found". Send it as 200.198.128, and > whois.arin.net will refer you to whois.lacnic.net. Send it to > whois.lacnic.net as 200.198.128, and you get "Invalid IP or CIDR > block". > > I realize programming around all this is by no means an > insurmountable task, but it is a pain. It'd be ideal if there were > a unique key field, say Net-ID included in the whois output from all > the RIR whois servers that could be used to identify the network and > the appropriate whois server. i.e. > > NetID: [EMAIL PROTECTED] In the current situation, users must query up to 4 servers (whois.apnic.net, whois.arin.net, whois.lacnic.net, and whois.ripe.net) to find information about an IP address, in some cases without any way of knowing which RIR has allocated the space. Each RIR parses queries and presents results in a different format. This is not ideal - to put it mildly. The good news is that we are aware of the problem, and not sitting on our laurels. The eventual goal is to answer a query for IP or AS space at each RIR, using the "native" query and result format, and get the best possible answer. We've completed part of the mapping between schemas, and after that is finished it's just a matter of writing some software. ;) There is also a technology that might come out of the CRISP IETF working group: http://www.ietf.org/html.charters/crisp-charter.html We (the RIR's) are tracking this work. Since this involves an actual protocol difference from our beloved Whois protocol, if it is adopted it will certainly take longer to adopt. But there is no reason the two protocols can't co-exist and complement each other. If you have any interest in participating in RIPE Database-related issues, please feel free to join the mailing list: http://www.ripe.net/ripe/wg/db/index.html We (meaning the RIPE NCC, especially the database group) take a lot of our direction from the DB working group. It's open to all. -- Shane Kerr Database Group Manager RIPE NCC
RE: DSL-IP Probes Curiousity..
> There is so much of it, I liken it to Internet background > radiation. In > fact, if I didnt see a constant stream of this (either by > accident-- SNMP > auto discovery, or design-- lets find all the 'private' routers and > switches out there) I would be more worried as my network > probably has been > blackholed! Good Point!! > > In terms of reporting it, I usually do if its more than just > some automated > probe and is a directed attack against a particular device > and is causing > some grief or potential grief. But it would be a full time > job evaluating > and responding to each and every scan/hack attempt as the > volume is way too > high. I think something like dshield is going in the right > direction. > Ultimately if these things are not reported and the people doing them > sanctioned somehow, it wont stop. Yeah, If a dshield type system is used and the ISP's can use that to add to the Abuse reports.. That would be great! > Also, its March Break in many parts of North America... More > time to do > these sorts of things. > Yeah, and don't forget spring exams in the AP Rim... That is always bad too J
The Cidr Report
This report has been generated at Fri Mar 14 21:45:21 2003 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
07-03-03120289 86148
08-03-03120272 86188
09-03-03120197 86257
10-03-03120223 86324
11-03-03120475 86388
12-03-03120508 86345
13-03-03120478 86334
14-03-03120659 86376
AS Summary
14740 Number of ASes in routing system
5812 Number of ASes announcing only one prefix
1562 Largest number of prefixes announced by an AS
AS701 : ALTERNET-AS UUNET Technologies, Inc.
73048064 Largest address span announced by an AS (/32s)
AS568 : SUMNET-AS DISO-UNRRA
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 14Mar03 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 120741863913435028.4% All ASes
AS3908 1097 537 56051.0% SUPERNETASBLK SuperNet, Inc.
AS18566 518 25 49395.2% COVAD Covad Communications
AS701 1562 1129 43327.7% ALTERNET-AS UUNET
Technologies, Inc.
AS4151 535 109 42679.6% USDA-1 USDA
AS7843 600 217 38363.8% ADELPHIA-AS Adelphia Corp.
AS4323 555 173 38268.8% TW-COMM Time Warner
Communications, Inc.
AS7018 1372 1021 35125.6% ATT-INTERNET4 AT&T WorldNet
Services
AS6197 499 160 33967.9% BATI-ATL BellSouth Network
Solutions, Inc
AS1221 1101 805 29626.9% ASN-TELSTRA Telstra Pty Ltd
AS1239 974 690 28429.2% SPRINTLINK Sprint
AS22927 295 14 28195.3% AR-TEAR2-LACNIC TELEFONICA DE
ARGENTINA
AS4355 391 119 27269.6% ERMS-EARTHLNK EARTHLINK, INC
AS705449 195 25456.6% ASN-ALTERNET UUNET
Technologies, Inc.
AS6198 451 200 25155.7% BATI-MIA BellSouth Network
Solutions, Inc
AS4814 264 15 24994.3% CHINANET-BEIJING-AP China
Telecom (Group)
AS1 656 431 22534.3% GNTY-1 Genuity
AS17676 230 27 20388.3% GIGAINFRA XTAGE CORPORATION
AS2386 480 280 20041.7% INS-AS AT&T Data
Communications Services
AS6347 370 171 19953.8% DIAMOND SAVVIS Communications
Corporation
AS22291 242 45 19781.4% CHARTER-LA Charter
Communications
AS4134 309 115 19462.8% CHINANET-BACKBONE
No.31,Jin-rong Street
AS690503 313 19037.8% MERIT-AS-27 Merit Network Inc.
AS209530 341 18935.7% ASN-QWEST Qwest
AS27364 258 84 17467.4% ACS-INTERNET Armstrong Cable
Services
AS2048 258 87 17166.3% LANET-1 State of Louisiana
AS17557 370 212 15842.7% PKTELECOM-AS-AP Pakistan
Telecom
AS6140 292 140 15252.1% IMPSAT-USA ImpSat
AS22773 184 33 15182.1% CCINET-2 Cox Communications
Inc. Atlanta
AS6327 187 40 14778.6% SHAWFIBER Shaw Fiberlink
Limited
AS7303 242 98 14459.5% AR-TAST-LACNIC Telecom
Argentina Stet-France Telecom
S.A.
Total 15774 7826 794850.4% Top 30 total
Please see http://www.cidr-report.org for the full report
Copies of this report are mailed to:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
