RED ALERT! heads up Quick security alert
SRI if this is OT, BUT, its a security related subject. Since most of us deal with UPS this info may be helpful. --- FYI ... Quick security alert: $32,000 worth of UPS uniforms have been purchased over the last 30 days by person(s) unknown on eBay. Law enforcement is working the case however no suspect(s) have been identified. Subjects may try to gain facility access by wearing these uniforms. If anyone has suspicions about a UPS delivery (i.e., no truck but driver, no UPS identification, etc.), contact UPS to verify employment. URGENT N.J. OFFICE OF COUNTER-TERRORISM ADVISORY Re: POSSIBLE IMPERSONATION OF UPS PERSONNEL SEEKING ACCESS TO BUILDINGS The New Jersey Office of Counter-Terrorism has received a report of an attempt by an unknown individual to enter a government facility by falsely posing as an employee of the United Parcel Service. Based on this incident, security personnel should exercise heightened vigilance when screening all delivery personnel at the entrances to all buildings and when accepting deliveries. Such measures should include careful inspection of credentials and identification of all delivery personnel to ensure that they are who they purport to be.
Re: RED ALERT! heads up Quick security alert
Unnamed Administration sources reported that blitz said: SRI if this is OT, BUT, its a security related subject. Since most of us deal with UPS this info may be helpful. --- FYI ... Quick security alert: $32,000 worth of UPS uniforms have been purchased over the last 30 days by person(s) unknown on eBay. Law enforcement is working the case however no suspect(s) have been identified. Subjects may try to gain facility access by wearing these uniforms. If anyone has suspicions about a UPS delivery (i.e., no truck but driver, no UPS identification, etc.), contact UPS to verify employment. Cite? Surely you can search eBay's completed sales and find the item numbers Hint: See alt.folklore.urban for this and and otherslike the bathtub and missing kidneys, JATO car, Capt. Hook... -- A host is a host from coast to [EMAIL PROTECTED] no one will talk to a host that's close[v].(301) 56-LINUX Unless the host (that isn't close).pob 1433 is busy, hung or dead20915-1433
RIPE Down or DOSed ?
Can anyone else get to ripe.net ? I cannot seem to access the whois or any other service (my ripe traffic goes through Sprint). When I ping peach.ripe.net, I get 90%+ missing packets + destination host unreachable from inside Sprint. Regards Marshall Eubanks
Re: RIPE Down or DOSed ?
From: Marshall Eubanks Can anyone else get to ripe.net ? I cannot seem to access the whois or any other service (my ripe traffic goes through Sprint). When I ping peach.ripe.net, I get 90%+ missing packets + destination host unreachable from inside Sprint. The same goes for me via qwest/Level3. peach.ripe.net PING Statistics 24 packets transmitted, 3 packets received, 87% packet loss round-trip (ms) min/avg/max = 127/127/127 -Jack
Re: RIPE Down or DOSed ?
I'm a bit closer than yuo, we see multiple flaps on their routes. 25396 15703 12859 193.109.219.130 from 193.109.219.130 (213.160.111.1) Origin IGP, localpref 150, valid, external Community: 6320:1004 6320:2002 6320:21238 15703:22001 25396:15703 Dampinfo: penalty 441, flapped 1 times in 00:02:46 7176 , (suppressed due to dampening) 195.66.224.74 from 195.66.224.74 (195.16.160.29) Origin IGP, metric 1090, localpref 100, valid, external Community: 6320:1004 6320:2003 6320:7176 Dampinfo: penalty 3298, flapped 14 times in 00:54:45, reuse in 00:32:00 1136 195.66.224.163 from 195.66.224.163 (194.151.224.192) Origin IGP, metric 70, localpref 150, valid, external, best Community: 6320:1004 6320:2002 6320:5459 Dampinfo: penalty 1899, flapped 7 times in 01:02:51 6461 12859 208.185.188.165 from 208.185.188.165 (207.126.96.50) Origin IGP, metric 721, localpref 150, valid, external Community: 6320:1004 6320:2002 6320:3000 6461 12859 195.66.224.76 from 195.66.224.76 (209.249.254.202) Origin IGP, metric 741, localpref 150, valid, external Community: 6320:1004 6320:2002 6320:5459 13237 12859 195.66.224.99 from 195.66.224.99 (80.245.35.6) Origin IGP, metric 20, localpref 150, valid, external Community: 6320:1004 6320:2002 6320:5459 12859:1000 12859:4000 Dampinfo: penalty 875, flapped 1 times in 00:02:54 3291 (history entry) 195.66.224.14 from 195.66.224.14 (154.14.65.2) Origin IGP, metric 20, localpref 150, external Community: 6320:1004 6320:2002 6320:5459 Dampinfo: penalty 1001, flapped 5 times in 01:03:26 On Thu, 27 Feb 2003, Marshall Eubanks wrote: Can anyone else get to ripe.net ? I cannot seem to access the whois or any other service (my ripe traffic goes through Sprint). When I ping peach.ripe.net, I get 90%+ missing packets + destination host unreachable from inside Sprint. Regards Marshall Eubanks
Fw: RIPE Down or DOSed ?
From: Remco van de Meent [EMAIL PROTECTED] [I cannot post on nanog hence this private mail] RIPE NCC just sent an email to the AMS-IX list stating that they are currently experiencing an ICMP DDOS attack. cheers, Remco.
Re: RIPE Down or DOSed ?
same here. both for 193.0.0.203 and 193.0.0.193 the buck stops at the KPN Internet Operator at 195.190.227.37 - Bert
Re: RIPE Down or DOSed ?
back to normal here AMS-IX 193.194.136.2 RIPE 193.0.0.193 - Bert
Change in homeland security threat level
Hi, NANOGers. For those of you tracking the DHS threat level - The Homeland Security threat level is very likely to be lowered one notch today, according to Marcus Sachs. Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
Lowering the Homeland Security Advisory Threat Level
CNN (and most other news sources) are reporting that the Department of Homeland Security is lowering the threat level from Orange to Yellow later today. There is no sign of any change on the Department of Homeland Security web site yet. Has any ISAC given out information to its members?
Re: RIPE Down or DOSed ?
And on a related topic (whois.ripe.net almost unreachable, along with the rest of RIPE): rwhois.level3.net:4321 as been MIA or AWOL for about 4 days: Level3 was informed, but seems to have some good reasons of their own not to fix this $ telnet rwhois.level3.net 4321 Trying 209.244.1.179... telnet: Unable to connect to remote host: Connection refused
Re: RIPE Down or DOSed ?
Thursday, February 27, 2003, 3:04:55 PM, Marshall wrote: Got told by an insider they are under a very nasty icmp attack, I guess they're little busy to get the chance to reply. -Subhi Can anyone else get to ripe.net ? I cannot seem to access the whois or any other service (my ripe traffic goes through Sprint). When I ping peach.ripe.net, I get 90%+ missing packets + destination host unreachable from inside Sprint. Regards Marshall Eubanks -- Best regards, Subhi S Hashwa mailto:[EMAIL PROTECTED] Operations Manager Electronic Corner Limited
Re: WorldCom's DWDM capabilities/OC12 SONET vs DWDM
Hi, On Thursday 27 February 2003 18:16, Max's Lists wrote: thanks all for your input. on closer examination I found that the only two countries in Europe where WorldCom seems to sell wavelength services retail are Belgium and Luxemburg. There is some talk about selling DWDM wholesale in Spain, but I am afraid this is just boilerplate language. WorldCom don't sell DWDM in Spain. They use capacity from other well know provideers. if anyone knows anything about how to figure out DWDM prices in those two countires ... i would be greatly appreciative If you need something in Spain mailme off list. Regards, Daniel
RIPE NCC network affected by the DDoS attack (fwd)
--- Forwarded Message Date: Thu, 27 Feb 2003 18:18:25 +0100 From: Andrei Robachevsky [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RIPE NCC network affected by the DDoS attack Dear Colleagues, Starting from 14:00 UTC today, 27 February, RIPE NCC network suffered a large DDoS attack. It was a distributed ICMP echo attack. The attack caused various congestion related problems for the RIPE NCC's network, to the extent that our BGP peering sessions were affected, and non-ICMP traffic was being randomly dropped. The attack was successfully mitigated with cooperation of our peer networks at AMS-IX. Network condition returned back to normal at 16:30 UTC. As a result some of our services, including www.ripe.net (web), whois.ripe.net (RIPE Database), ns.ripe.net (DNS) and ftp.ripe.net (FTP) were not accessible during this timeframe. Now all services are back to normal. Regards, Andrei Robachevsky CTO, RIPE NCC --- End of Forwarded Message
Re: RIPE Down or DOSed ?
On Thu, Feb 27, 2003 at 11:09:19AM -0500, [EMAIL PROTECTED] wrote: And on a related topic (whois.ripe.net almost unreachable, along with the rest of RIPE): rwhois.level3.net:4321 as been MIA or AWOL for about 4 days: Level3 was informed, but seems to have some good reasons of their own not to fix this $ telnet rwhois.level3.net 4321 Trying 209.244.1.179... telnet: Unable to connect to remote host: Connection refused There is no public access to rwhois.level3.net (it worked at one point, but, accurding to Level3, not intentionally). They say that they don't have to make this information available to anyone except ARIN. I was always under the impression that delegations had to be publicly visible, but looking at ARIN's policy more closely, it seems that the information only has to be available to ARIN. -- Since when is skepticism un-American? Dissent's not treason but they talk like it's the same... (Sleater-Kinney - Combat Rock)
Re: RIPE Down or DOSed ?
On 2/27/2003 at 10:44:49 -0800, Will Yardley said: On Thu, Feb 27, 2003 at 11:09:19AM -0500, [EMAIL PROTECTED] wrote: And on a related topic (whois.ripe.net almost unreachable, along with the rest of RIPE): rwhois.level3.net:4321 as been MIA or AWOL for about 4 days: Level3 was informed, but seems to have some good reasons of their own not to fix this $ telnet rwhois.level3.net 4321 Trying 209.244.1.179... telnet: Unable to connect to remote host: Connection refused There is no public access to rwhois.level3.net (it worked at one point, but, accurding to Level3, not intentionally). They say that they don't have to make this information available to anyone except ARIN. I was always under the impression that delegations had to be publicly visible, but looking at ARIN's policy more closely, it seems that the information only has to be available to ARIN. If the ARIN server recurses properly, you should be able to pull it out that way. So hiding it from everybody but ARIN doesn't make the information unavailable. They're probably sheltering themselves from security concerns in the server. -Dave
Re: Root server error
On Thu, Feb 27, 2003 at 02:21:20PM -0500, Geo. wrote: Can someone verify something for me? Do an NSLOOKUP for www.stemtostern.com and stemtostern.com against the i.gtld-servers.net why would the www one resolve? It's stale glue; i.e., there's a host (nameserver) record for this address. Delete or modify the record. jazz% whois www.stemtostern.com Whois Server Version 1.3 Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. Server Name: WWW.STEMTOSTERN.COM IP Address: 216.144.36.50 Registrar: NETWORK SOLUTIONS, INC. Whois Server: whois.networksolutions.com Referral URL: http://www.networksolutions.com jazz% dig @b.gtld-servers.net www.stemtostern.com +norec ; DiG 9.3.0s20021217 @b.gtld-servers.net www.stemtostern.com +norec ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 57571 ;; flags: qr; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.stemtostern.com. IN A ;; ANSWER SECTION: www.stemtostern.com.172800 IN A 216.144.36.50 ;; AUTHORITY SECTION: stemtostern.com.172800 IN NS NS1.NLS.NET. stemtostern.com.172800 IN NS NS2.NLS.NET. ;; ADDITIONAL SECTION: NS1.NLS.NET.172800 IN A 216.144.0.10 NS2.NLS.NET.172800 IN A 216.144.0.11 ;; Query time: 17 msec ;; SERVER: 192.33.14.30#53(b.gtld-servers.net) ;; WHEN: Thu Feb 27 11:59:29 2003 ;; MSG SIZE rcvd: 128 -- Since when is skepticism un-American? Dissent's not treason but they talk like it's the same... (Sleater-Kinney - Combat Rock)
Re: Root server error
On Thu, 27 Feb 2003, Geo. wrote: Can someone verify something for me? Do an NSLOOKUP for www.stemtostern.com and stemtostern.com against the i.gtld-servers.net why would the www one resolve? If an A (or ) record appears in the com or net zones, it's because it is referenced at least one NS record also in the com and net zones, i.e., it appears on the right side of an NS record. This is the case with www.stemtostern.com. While it is not a name server for stemtostern.com, it is a name server for harbormarinetowing.com; please see the dig output below. Matt -- Matt Larson [EMAIL PROTECTED] VeriSign Global Registry Services ; DiG 9.2.1 +norec @a.gtld-servers.net ns harbormarinetowing.com ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 41821 ;; flags: qr; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 ;; QUESTION SECTION: ;harbormarinetowing.com.IN NS ;; ANSWER SECTION: harbormarinetowing.com. 172800 IN NS ns.nls.net. harbormarinetowing.com. 172800 IN NS www.stemtostern.com. ;; ADDITIONAL SECTION: ns.nls.net. 172800 IN A 216.144.8.10 www.stemtostern.com.172800 IN A 216.144.36.50 ;; Query time: 24 msec ;; SERVER: 192.5.6.30#53(a.gtld-servers.net) ;; WHEN: Thu Feb 27 15:32:09 2003 ;; MSG SIZE rcvd: 126
Re: RIPE Down or DOSed ?
On 2/27/2003 at 1:44 PM, [EMAIL PROTECTED] (Will Yardley) wrote: There is no public access to rwhois.level3.net (it worked at one point, but, accurding to Level3, not intentionally). They say that they don't have to make this information available to anyone except ARIN. I was always under the impression that delegations had to be publicly visible, but looking at ARIN's policy more closely, it seems that the information only has to be available to ARIN. Secrecy over a public resource = no oversight = facilitator of abuse. It has worked as long as I can remember, and them intentionally shutting it off is completely against letter and spirit of ARIN's allocation policy: rwhois, or SWIP delegations, but not none of the above. 7018 Realized this for 12.0.0.0/8 at some point. Why do I get the distinct feeling that this move by Level3 is aimed not at creating greater customer privacy (it never served POC email addresses), or protecting themselves from getting their customer base poached by other providers, but at preventing people from identifying spamming Level3 customers (of which they seem to have 100's) by organization name and being able to correlate activity from different netblocks of theirs. So instead of select prefixes, most longer than /24 appearing in the various DNSBLs that do manual listing by organization (Spamhaus SBL, SPEWS, Wirehub), Level3 customers can now look forward to /24 to /17 knock-outs that should absolutely positive cover the hiding criminal scum they so willingly receive money from. And then some. If you are a Level3 customer using Level3 IP space, you might want to expediously insist that your IP space delegation appears at whois.arin.net properly, or else consider a new network provider or buying yourself your own /16 on the grey market^W^W^W^Wacquire a defunct company with a mostly unused /16. What did Randy once say? I welcome my competitors running their networks this way (paraphrased)
RE: Root server error
Matt Larson wrote: On Thu, 27 Feb 2003, Geo. wrote: Can someone verify something for me? Do an NSLOOKUP for www.stemtostern.com and stemtostern.com against the i.gtld-servers.net why would the www one resolve? If an A (or ) record appears in the com or net zones, it's because it is referenced at least one NS record also in the com and net zones, i.e., it appears on the right side of an NS record. Is it _finally_ possible then, to get a record as glue into the com/net/org zones? This is the case with www.stemtostern.com. While it is not a name server for stemtostern.com, it is a name server for harbormarinetowing.com; please see the dig output below. Matt -- Matt Larson [EMAIL PROTECTED] VeriSign Global Registry Services Greets, Jeroen
Cidera will be back up
By midnight, providing the bandwidth challenged UseNet feeds again. WebUseNet will make an announcement of our business deal with Cidera in the near future. We are glad we were able to help save this important resource on the Internet. Dwight Ringdahl WebUseNet
ebgp-multihop
Hi - I have searched the archives but have not found an answer to my question - is there any danger in using excessively high TTL values with ebgp-multihop? For example, neighbor x.x.x.x ebgp-multihop 255 - 255 is generally much higher than needed, but is there any risk/danger ?? Thanks in advance. - Tim Tim Rand Network Engineer OHSU Information Technology Group ph: 503.418.1045 fx: 503.494.7143
Re: ebgp-multihop
On Thu, 27 Feb 2003, Tim Rand wrote: I have searched the archives but have not found an answer to my question - is there any danger in using excessively high TTL values with ebgp-multihop?For example, neighbor x.x.x.x ebgp-multihop 255 - 255 is generally much higher than needed, but is there any risk/danger ??Thanks in advance. - Tim If you use this for a regular BGP feed (one where you actually send traffic as per the routes received) you can get interesting results if your direct connection to the peer goes down. Your BGP session will probably survive this and simply continue to run over any other connection(s) to the net you have. You can of course make sure this doesn't happen by creative application of static routes with different administrative distances (or even a filter).
Re: ebgp-multihop
* Tim Rand [EMAIL PROTECTED] [030227 16:39]: Hi - I have searched the archives but have not found an answer to my question - is there any danger in using excessively high TTL values with ebgp-multihop? For example, neighbor x.x.x.x ebgp-multihop 255 - 255 is generally much higher than needed, but is there any risk/danger ?? Thanks in advance. - Tim There is a potential for blackholing traffic should you be dual (or multi) homed and if the ebgp-multihop session were able to re-establish over another path. Better to keep it close to what you'd expect your maximum number of hops to be to reduce the potential for undesirable modes. -Steve
Re: ebgp-multihop
From: Tim Rand Hi - I have searched the archives but have not found an answer to my question - is there any danger in using excessively high TTL values with ebgp-multihop? For example, neighbor x.x.x.x ebgp-multihop 255 - 255 is generally much higher than needed, but is there any risk/danger ?? Thanks in advance. - Tim The number of hops in an ebgp-multihop scenario isn't usually the concern. When using ebgp sessions to null route baddies, the peer can be an unspecified number of hops away. I would consider 255 to be overkill, but not much harm. In normal routing, I would try to keep the hop count within 1 or 2. It's just a good practice. Remember, every router between the two sessions has to also know the route. Perhaps some of the older folks have some better tidbits of advice. -Jack
Re: Root server error
Perhaps it is GLUE for an NS record. Owen --On Thursday, February 27, 2003 2:21 PM -0500 Geo. [EMAIL PROTECTED] wrote: Can someone verify something for me? Do an NSLOOKUP for www.stemtostern.com and stemtostern.com against the i.gtld-servers.net why would the www one resolve? Geo.
Re: RIPE Down or DOSed ?
On Thu, 27 Feb 2003, Kai Schlichting wrote: Secrecy over a public resource = no oversight = facilitator of abuse. Why do I get the distinct feeling that this move by Level3 is aimed not at creating greater customer privacy (it never served POC email addresses), or protecting themselves from getting their customer base poached by other providers, but at preventing people from identifying spamming Level3 customers (of which they seem to have 100's) by organization name and being able to correlate activity from different netblocks of theirs. Though I agree, Level3 seems to host a good number of spammers, they're by no means the only guilty party. Pulled at random from recent spams I've submitted to NJABL are 69.6.4.104, 69.6.4.114, and 69.6.4.156. whois @arin.net yields the following: ... NetRange: 69.6.0.0 - 69.6.63.255 CIDR: 69.6.0.0/18 NetName:WHOLE-2 NetHandle: NET-69-6-0-0-1 Parent: NET-69-0-0-0-0 NetType:Direct Allocation NameServer: NS1.WHOLESALEBANDWIDTH.COM NameServer: NS2.WHOLESALEBANDWIDTH.COM ... Where are the swips? The rest of that record makes no mention of an rwhois server. Doing a bunch of whois requests for IPs in that block, I found only one swip (for a /21). I realize the ARIN regs don't seem to require that reassignment info be made available to the public (just to ARIN), but using your innocent customers (if there are any) as a shield to hide your spammer customers is just wrong. Should I block 69.6.4.0/24 from sending email into my systems? 69.6.0.0/18? http://www.njabl.org/cgi-bin/lookup.cgi?query=69.6.4.104 http://www.njabl.org/cgi-bin/lookup.cgi?query=69.6.4.114 http://www.njabl.org/cgi-bin/lookup.cgi?query=69.6.4.156 -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: ebgp-multihop
No! eBGP multihop carries with it the implicit possiblity of session highjacking - in a normal (Multihop=1) session, the router would not be able to find a duplicate neighbor with the specified IP address directly connected. Obviously, once you're saying that the neighbor could be anywhere in the world, what's to prevent me assigning my home Macintosh with a second IP address and injecting whatever I want into your network? Second, Multihop is really a kludge: eBGP is ideally run at the edge of a network across a point-to-point (or shared) medium, and there really shouldn't be multiple paths to eBGP neighbors. If your link to ISP X goes away, do you really want to have your router think that ISP X is still available? Or would you rather just fail-over to a backup path? iBGP is another matter - there you want 255, b/c you want the sessions to stay up even in the event of a backbone link flap. --- Iljitsch van Beijnum [EMAIL PROTECTED] wrote: On Thu, 27 Feb 2003, Tim Rand wrote: I have searched the archives but have not found an answer to my question - is there any danger in using excessively high TTL values with ebgp-multihop? For example, neighbor x.x.x.x ebgp-multihop 255 - 255 is generally much higher than needed, but is there any risk/danger ??Thanks in advance. - Tim If you use this for a regular BGP feed (one where you actually send traffic as per the routes received) you can get interesting results if your direct connection to the peer goes down. Your BGP session will probably survive this and simply continue to run over any other connection(s) to the net you have. You can of course make sure this doesn't happen by creative application of static routes with different administrative distances (or even a filter). = David Barak -fully RFC 1925 compliant- __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
Re: ebgp-multihop
On Thu, Feb 27, 2003 at 07:29:29PM -0800, David Barak wrote: No! eBGP multihop carries with it the implicit possiblity of session highjacking - in a normal (Multihop=1) Everyone uses md5 signature/bgp password/ authentication keys correct? That means this isn't an issue :) session, the router would not be able to find a duplicate neighbor with the specified IP address directly connected. Obviously, once you're saying that the neighbor could be anywhere in the world, what's to prevent me assigning my home Macintosh with a second IP address and injecting whatever I want into your network? Second, Multihop is really a kludge: eBGP is ideally run at the edge of a network across a point-to-point (or shared) medium, and there really shouldn't be multiple paths to eBGP neighbors. If your link to ISP X goes away, do you really want to have your router think that ISP X is still available? Or would you rather just fail-over to a backup path? iBGP is another matter - there you want 255, b/c you want the sessions to stay up even in the event of a backbone link flap. Depends on the size of the flap and router convergence times. - Jared
anti-spam vs network abuse
We (Atlantic.Net) have gotten a flurry of abuse complaints from people who's systems have been scanned by 209.208.0.15 (rt.njabl.org...a DNSBL hosted on our network). I'm hoping the new PTR record will head off many complaints now. For the past 15 months, NJABL has reactively tested systems that have connected to participating SMTP servers to see if those systems are open relays. Just over a week ago, NJABL added open proxy testing to its relay testing software. The proxy testing checks for a variety of common proxy software/protocols on about 20 different ports simultaneously. This is apparently setting off some IDS/firewall alarms. We do not consider what NJABL does abuse, and we reply to all the complaints explaining that the complainant should go have a look at http://njabl.org/ and hopefully they'll understand why their system was scanned. This sort of activity is becoming more common / mainstream, so people ought to just get used to it. Road Runner is doing the same thing (according to http://sec.rr.com/probing.htm) which is pretty ironic given how their security department has gotten along with (or not) various DNSBLs in the past. BTW...in the week that NJABL has been testing for open proxies, more than 18000 have been detected, pretty much all of which are actively being abused by spammers, else mail would not have come through them. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: anti-spam vs network abuse
From: [EMAIL PROTECTED] We (Atlantic.Net) have gotten a flurry of abuse complaints from people who's systems have been scanned by 209.208.0.15 (rt.njabl.org...a DNSBL hosted on our network). I'm hoping the new PTR record will head off many complaints now. For the past 15 months, NJABL has reactively tested systems that have connected to participating SMTP servers to see if those systems are open relays. Just over a week ago, NJABL added open proxy testing to its relay testing software. The proxy testing checks for a variety of common proxy software/protocols on about 20 different ports simultaneously. This is apparently setting off some IDS/firewall alarms. We do not consider what NJABL does abuse, and we reply to all the Ahh, yes. The age old debate. So long as you, their provider, doesn't consider it abuse, they should be relatively safe. Obviously, there are some net blocks up to stop the probes. There always are and always will be. Networks don't like scans. One thing I'll say about NJABL, it's probably the most accurate list for what it does. With the added proxy testing, they'll get more people using the list, along with more complaints. I'll be adding my log IP's to that list soon enough. -Jack
Re: anti-spam vs network abuse
On Thu, 27 Feb 2003 22:36:37 -0500 (EST), [EMAIL PROTECTED] wrote: This sort of activity is becoming more common / mainstream, so people ought to just get used to it. Road Runner is doing the same thing (according to http://sec.rr.com/probing.htm) which is pretty ironic given how their security department has gotten along with (or not) various DNSBLs in the past. It has always been my opinion that if somebody connects to you, they are implicitly granting you the right to connect back to them on well-known ports. I have discussed this opinion with several dozen people and have yet to find one who disagrees. (Though I'm sure they're probably out there.) I've dealt with any number of abuse complaints, many from governmental and quasi-governmental group. They've all accepted my cut/pasted explanation and we've been whitelisted by several such organizations. I often use the following as the 'meat' paragraph of my reply: In accord with our terms of service, when someone makes a connection to one of our machines, we make connections back to them to ensure they're not connecting through an open proxy. These connections are to each of the ports on which such proxies commonly run and some ports may require more than one connection to test multiple protocols. We never do such a probe except as a response to a connection made to us. -- David Schwartz [EMAIL PROTECTED]
Q: How to avoid retaining portable class C?
I realize this is a little too non-operational for the list, but I stupervise a 750 desktop net with a portable class C when I haven't lost myself in the pub. We use about (approximately) 6 of those 253 useable addr's. I could cut that down to 4, I think. I don't think we're worthy of the cross-ISP portable subnet. The company is nearly 100 years old (in Canada!) but we just use email/user surf. Can anyone share advice about how I might communicate this is generally bad 'cause of BGP table size issues to a non-technical manager..? This individual thinks our netblock is a continued reason for his/her employment, as per usual. Off-List replies would be appreciated. (416) 432-4334. Anytime. -- Scott.
