Re: RBLs in use
While on the subject of dnsbls, I would like to bounce an idea off the list. I would like to find out of there anything in existance like this and if there would be interest in an implementation. I must admit that I have not checked every single dnsbl, but as far as I could tell, there doesnt seem to be any that work like the way I am going to describe. If there are, I would like to find out. Consider a dnsbl that provides delegation only information as to the nameservers which contain the zones of ip addresses of non-mail sending hosts. Basically like a dialup or dynamic ip dnsbl, but it would hopefully be more accurate and complete since the management of the zone would be delegated to the ISP. ISPs would register their networks and authenticate via ARIN/RIR contact email. The nameserver could be mapped to the same as the in-addr.arpa or maybe allow the addresses to be specified. What would the drawbacks be? Well, you wouldn't be able to do a zone transfer of the actual data. Of course, the dns servers would probably be the same ones you are checking for the PTR records and other info, so if there is a problem with them you may reject/defer the mail anyway. I would be interested to hear if anyone can think of any drawbacks or security implications. I should also mention, that it would be possible (assuming the proper coordination) to just define a zone 'in-dnsbl.arpa' for argument sake, and delegate the networks to the existing 'in-addr.arpa' servers (maybe via some fancy zone name mapping option in the dns server). This would mean there is no central authority to attack (other than the in-addr.arpa' servers). The drawback would be lots of unwanted traffic to nameservers that never configured the zones. That is why I prefer the registration, method. +--+ | Michael MoscovitchCiteNet Telecom Inc. | | [EMAIL PROTECTED] Tel: (514) 861-5050| +--+
Re: Increase in traffic to/from DSL subs since August?
Steven M. Bellovin writes on 11/20/2003 4:28 PM: At the IETF Plenary, Bernard Aboba showed a graph of spam, with a marked uptick since SoBig.F in August. My guess is worm-deposited spam relays, though Joel's guess of Nachi or Welchia can't be ruled out, either, without flow data. A ballpark estimate from a couple of friends who run small cable ISPs in India, and from a look at our mailserver log stats, says that yes, this is mostly because of open proxies and trojans infecting unpatched windows machines on broadband. Swen, MiMail and Jeem.mail.pv seem to be the worst offenders wrt spamming trojans, right now. Nachi and Welchia are almost as bad. I'd say blame can be split equally between the two. -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
Re: [nsp] Re: Per VLAN Stats on MSFC2 - Complaints from the Field
This too is a discussion argued a number of times previously. Personally, I prefer the architecture where one port belongs to one VLAN; this is obviously not appropriate in all situations, but it is in mine. Nothing in this world is free, and the bandwidth that a customer uses across my network is not either, regardless if it's in between their own two servers. In instances where a customer has multiple machines which require communication between one another, it is held at the customers discretion to purchase a private switch and second NIC(s), so our billing system remains ignorant, or get billed for the traffic. If you are someone who enjoys living dangerously, there are also a variety of Flow based accounting systems and Probes which would allow you to bill based on the flow/IP accounting, rather than SNMP on your access devices. This can be done either through your choice Layer 3 device or a third-party promiscuous probe. I'm sure that everybody here has their own idea on best how to do this, and what is 'right' for them; my argument is only that falsifying data through propagation from multi layer switching does not at all seem to be the best way. Christopher L. Morrow wrote: On Thu, 20 Nov 2003, Anthony Cennami wrote: If you want to bill accurately, bill off the Layer 2 ports; that's what is always churning the traffic. I've not looked at the accuracy on a scientific level, but I've never found what I believed to be a serious discrepency when billing/polling the physical ports. What about the cases where the customer has more than 1 port on your switch, you must then aggregate the traffic from N ports, discount the data between the local hosts and only bill for the actual up/down from the switch to the core, no? That seems complex, of course perhaps only 1 port per customer makes some sense in these cases too, eh?
Re: RBLs in use
I'm gonna post this back publically because it will be of interest to all (I hope)... Jasper van Beusekom wrote: Mat: Noone is exempt from listing in SORBS, but proven whitehats don't get blocked. Do you have many such contacts? I have a few (less than 50) Would it be something to create a DNSBL list for known whitehats and sites with functioning abuse teams? Such a whitelist could be a partial implementation of a 'trusted network' principle. I am *currently* creating an extension to SORBS which will allow ISPs to register as whitehats along with their mailservers and netblocks, and a fast response email address. The idea being if a mailserver is about to be listed they will get 24 hours warning to avert the listing. If addresses within their netblocks get listed they will get notification mails, and the host is listed immediately. A similar project runs under the DNSBL domain: nlwhitelist.dnsbl.bit.nl Usenet reference unfortunately in Dutch: [EMAIL PROTECTED] Basically, respectable ISPs with active abuse desks can request to get listed, and will be removed when complaints start coming in. Whitelists wouldn't attract the same kind of DDoS activities either. I think I'll still be a DDoS target though ;-/ Yours Mat
Re: [nsp] Re: Per VLAN Stats on MSFC2 - Complaints from the Field
On Thu, 20 Nov 2003, Gert Doering wrote: > This is all nice and shiny, but having shortcuts doesn't mean "the L2 > fabric can't export the resulting numbers up to the L3 brain". > > They just botched it. Counters and Cisco boxes seem to be fundamentally > incompatible. I was under the impression that the information you want is lost once the packets are being forwarded by the switch which is using some hashing on the src and dst details which doesnt tie back to the L3 data in a one-to-one basis... Anyway, on a similar thread that doesnt explain why mac accounting cant be used which I used to find very useful on non p2p interfaces... Steve
Re: [nsp] Re: Per VLAN Stats on MSFC2 - Complaints from the Field
On Thu, 20 Nov 2003, Anthony Cennami wrote: > > If you want to bill accurately, bill off the Layer 2 ports; that's what > is always churning the traffic. I've not looked at the accuracy on a > scientific level, but I've never found what I believed to be a serious > discrepency when billing/polling the physical ports. > What about the cases where the customer has more than 1 port on your switch, you must then aggregate the traffic from N ports, discount the data between the local hosts and only bill for the actual up/down from the switch to the core, no? That seems complex, of course perhaps only 1 port per customer makes some sense in these cases too, eh?
Re: [nsp] Re: Per VLAN Stats on MSFC2 - Complaints from the Field
If you want to bill accurately, bill off the Layer 2 ports; that's what is always churning the traffic. I've not looked at the accuracy on a scientific level, but I've never found what I believed to be a serious discrepency when billing/polling the physical ports. The reporting of the Layer 2 and 3 devices, virtual or otherwise appears to be correct; I argue that Cisco attempting to 'populate' the SVI counters with information they are actually not seeing would be 'breaking' the implementation. Remember folks, we're talking about multi layer switching/routing here; the SVI isn't processing all of the traffic and should not lie and say that it is. Hudson Delbert J Contr 61 CS/SCBN wrote: cisco long ago made the decision that counting packets was NOT as important processing them. i've seen this thread in discussions about IOS since Version 9. they arent going to change the methodology right now because we need to bill off of it. why use the overhead involved with passing info about L2 to L3 if 'train is still moving the cattle'. who cares? ~v/r Del Hudson 61CS/SCBN - LAAFB NCC Network Architecture & Engineering Group [EMAIL PROTECTED] -Original Message- From: Gert Doering [mailto:[EMAIL PROTECTED] Sent: Thursday, November 20, 2003 1:43 PM To: Anthony Cennami Cc: Nanog Mailing list; Robert A. Hayden; [EMAIL PROTECTED] Subject: Re: [nsp] Re: Per VLAN Stats on MSFC2 - Complaints from the Field Hi, On Thu, Nov 20, 2003 at 12:52:02PM -0500, Anthony Cennami wrote: This is because in 1996 you were likely not dealing with 'Switch Routers'; today's 'routers' perform some form of flow switching/caching, meaning once the traffic enters the VLAN routed interface and an appropriate path is found it is sent down the the Layer 2 fabric. This is all nice and shiny, but having shortcuts doesn't mean "the L2 fabric can't export the resulting numbers up to the L3 brain". They just botched it. Counters and Cisco boxes seem to be fundamentally incompatible. gert
Re: RBLs in use
Suresh Ramasubramanian wrote: Kai Schlichting <[EMAIL PROTECTED]> writes: BT have (quite rightly) been repeatedly blocked by DNSBL's and private lists as a result of their poor record in handling abuse incidents (whether that's by intent or negligence by way of a colossal management failure is another debate entirely). How sure are you, beyond just the usual nan(og|ae) idle chatter? BT is much better off than some ISPs I can think of. I do happen to know they have a few good people in there working for them. There are? SORBS has been listing BT for some time now because of the continual stream of spam to the spamtraps, and first contact was made within the last 7 days - and from memory that mail appear to be a bit of throwing ones weight around (which doesn't wash with me at all - everyone is treated the same, and if I am treated with respect I treat others with respect). If the guy is asking for DNSBLs to use, and you have some good ones in mind, help him, I'd say. I agree, though based on the recent communication I wonder whether someone is after finding out whether they should be able to safely ignore lists such as mine ... ;-/ Yours Mat PS: If there are BT staffers here with clout, you might want to contact me over the listings. Noone is exempt from listing in SORBS, but proven whitehats don't get blocked.
Re: RBLs in use
On Fri, 21 Nov 2003, Suresh Ramasubramanian wrote: > If the guy is asking for DNSBLs to use, and you have some good ones in > mind, help him, I'd say. Here Here Suresh, you're on the money! If they (BT) really have that big of a problem, one could look at this as a sign that they want to see what effect its had on their network, and they might *GHASP* fix it. Rather than pointing fingers and attacking, help the poor guy!
Apologies but...Verizon Postmaster?
I have been trying for weeks to get in touch with someone who will respond with something other than a form letter at Verizon. Can someone please contact me off-list? My company (Modwest) is being unilaterally blocked. I can't even send mail to abuse, postmaster, etc. from an @modwest.com address because of the block in place without a reason and without recourse. TIA, and I'm sorry for posting here but it's really my last resort (as it should be anyones IMHO). -- GPG/PGP --> 0xE736BD7E 5144 6A2D 977A 6651 DFBE 1462 E351 88B9 E736 BD7E pgp0.pgp Description: PGP signature
Re: Increase in traffic to/from DSL subs since August?
: >Another independent ISP operator and I have noticed a pretty significant : >increase in traffic to and from our broadband (DSL) subscribers since : >August. It's been a fairly steady uptick, at least in my case, resulting : >in a doubling of overall average traffic to/from these folks since then. : > : >Have others seen a similar trend? Any thoughts as to what the cause may : >be? Our best guess a virus/worm, possibly being used as a spam relay or : >other proxy at this point... : At the IETF Plenary, Bernard Aboba showed a graph of spam, with a : marked uptick since SoBig.F in August. My guess is worm-deposited spam : relays, though Joel's guess of Nachi or Welchia can't be ruled out, : either, without flow data. Don't forget the NTFS ADS spam crap. >:-( scott
Re: Increase in traffic to/from DSL subs since August?
Jared B. Reimer wrote: Greetings. Another independent ISP operator and I have noticed a pretty significant increase in traffic to and from our broadband (DSL) subscribers since August. It's been a fairly steady uptick, at least in my case, resulting in a doubling of overall average traffic to/from these folks since then. Have others seen a similar trend? Any thoughts as to what the cause may be? Our best guess a virus/worm, possibly being used as a spam relay or other proxy at this point... Welchia would generate large amounts of traffic from the subscribers but not really that much towards them because it sends it´s traffic to random IP prefixes, thus possibility of hitting local prefixes is not that great. (cannot remember if it had some bias) Most consumer heavy networks which used to have spare capacity in the DSL access enjoy instant traffic growth if they or their upstream upgrades their peers, making more bandwidth available to p2p applications. And last, not least, zombierunners from certain netblocks probably send instructions to your users to spew messages around the world advertising their wares. Just as a side note, we recently announced product to automatically sandbox and un-sandbox infected machines. Works with dynamic addresses also. Pete
Re: Increase in traffic to/from DSL subs since August?
At 04:28 PM 20/11/2003, Steven M. Bellovin wrote: At the IETF Plenary, Bernard Aboba showed a graph of spam, with a marked uptick since SoBig.F in August. My guess is worm-deposited spam relays, though Joel's guess of Nachi or Welchia can't be ruled out, either, without flow data. I would say all of the above, plus the normal "back from summer holidays, weather is getting worse, lets go on-line instead" phenomena, and "there is now more to do online including cool higher bandwidth net content" all add to higher usage. But I would certainly say worm traffic is a big one. ---Mike
Re: Increase in traffic to/from DSL subs since August?
In message <[EMAIL PROTECTED]>, "Jared B. Reimer" wr ites: > >Greetings. > >Another independent ISP operator and I have noticed a pretty significant >increase in traffic to and from our broadband (DSL) subscribers since >August. It's been a fairly steady uptick, at least in my case, resulting >in a doubling of overall average traffic to/from these folks since then. > >Have others seen a similar trend? Any thoughts as to what the cause may >be? Our best guess a virus/worm, possibly being used as a spam relay or >other proxy at this point... > At the IETF Plenary, Bernard Aboba showed a graph of spam, with a marked uptick since SoBig.F in August. My guess is worm-deposited spam relays, though Joel's guess of Nachi or Welchia can't be ruled out, either, without flow data. --Steve Bellovin, http://www.research.att.com/~smb
Re: Increase in traffic to/from DSL subs since August?
On Thursday, November 20, 2003 10:00 PM, Jared B. Reimer <[EMAIL PROTECTED]> wrote: > Greetings. > > Another independent ISP operator and I have noticed a pretty significant > increase in traffic to and from our broadband (DSL) subscribers since > August. It's been a fairly steady uptick, at least in my case, resulting > in a doubling of overall average traffic to/from these folks since then. > > Have others seen a similar trend? Any thoughts as to what the cause may > be? Our best guess a virus/worm, possibly being used as a spam relay or > other proxy at this point... > Traffic at LINX and AMS-IX started to grow again in Juli/August as well after having slowed down for months. At DE-CIX we see also a bis increase in traffic since August. No idea what this is. IMHO it's to much traffic for being virus/worm. Arnold
Re: Increase in traffic to/from DSL subs since August?
icmp followed by port 135 connection attempts? nachi or welchia... flow logs are highly useful in understanding gross behavioral changes in user usage patterns. joelja On Thu, 20 Nov 2003, Jared B. Reimer wrote: > > Greetings. > > Another independent ISP operator and I have noticed a pretty significant > increase in traffic to and from our broadband (DSL) subscribers since > August. It's been a fairly steady uptick, at least in my case, resulting > in a doubling of overall average traffic to/from these folks since then. > > Have others seen a similar trend? Any thoughts as to what the cause may > be? Our best guess a virus/worm, possibly being used as a spam relay or > other proxy at this point... > > Many thanks, > > -- Jared > -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Increase in traffic to/from DSL subs since August?
Greetings. Another independent ISP operator and I have noticed a pretty significant increase in traffic to and from our broadband (DSL) subscribers since August. It's been a fairly steady uptick, at least in my case, resulting in a doubling of overall average traffic to/from these folks since then. Have others seen a similar trend? Any thoughts as to what the cause may be? Our best guess a virus/worm, possibly being used as a spam relay or other proxy at this point... Many thanks, -- Jared
Re: RBLs in use
Kai Schlichting <[EMAIL PROTECTED]> writes: > BT have (quite rightly) been repeatedly blocked by DNSBL's and private > lists as a result of their poor record in handling abuse incidents (whether > that's by intent or negligence by way of a colossal management failure is > another debate entirely). How sure are you, beyond just the usual nan(og|ae) idle chatter? BT is much better off than some ISPs I can think of. I do happen to know they have a few good people in there working for them. If the guy is asking for DNSBLs to use, and you have some good ones in mind, help him, I'd say. --srs -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
Re: RBLs in use
Brian Bruns wrote: I run the Abusive Hosts Blocking List (http://www.ahbl.org). We list everything from spam sources, to spam supporters, open proxies, open relays, drones, etc. Its in use on all of the mail servers I help administrate (which includes several fortune 500 companies, half a dozen regional ISPs, and several .edu sites), plus SpamHaus, SpamCop BL, SORBS, EasyNet, and several others, which help balance out protection. Like what .edu's and fortune 500 companies? -davidu David A. Ulevitch - Founder, EveryDNS.Net Washington University in St. Louis http://david.ulevitch.com -- http://everydns.net
Re: RBLs in use
and then there's the granddaddy of them all, MAPS. see www.mail-abuse.org. -- Paul Vixie
Re: RBLs in use
On 11/20/2003 at 10:51 AM, "Paul S. Brown" <[EMAIL PROTECTED]> wrote: > Nope, > Just an ISP with normal ISP type operational spam problems. I'm trying to > quantify how often we actually appear on RBL, but I want to get some idea of > how much credence to give to appearing on any given list. > For example something like the old Dorkslayers lists should be ignored because > they would blacklist you if you sneezed at the wrong time, however MAPS is > probably a good list. > P. Based on what you said in http://groups.google.com/groups?selm=bneav9%2410frig%241%40ID-169718.news.uni-berlin.de&oe=UTF-8&output=gplain you appear to be working for BT (British Telecom). BT have (quite rightly) been repeatedly blocked by DNSBL's and private lists as a result of their poor record in handling abuse incidents (whether that's by intent or negligence by way of a colossal management failure is another debate entirely). Are you looking to apply leverage internally to arrange for that situation to change, or are you (perhaps) attempting to gather information which your employer can use to harass or pursue DNSBL maintainers or other spam foes in some way?" I have several individuals privately voicing this suspicion to me, along with other wild suspicions, like: has BT hired Mark E. "Felonstein" Felstein to provide legal advice based on his impeccable experience gained in the E-Marketers of America vs. SPEWS et.al. case? (http://www.spamhaus.org/legal/index.html) bye,Kai
Re: Per VLAN Stats on MSFC2 - Complaints from the Field
This is because in 1996 you were likely not dealing with 'Switch Routers'; today's 'routers' perform some form of flow switching/caching, meaning once the traffic enters the VLAN routed interface and an appropriate path is found it is sent down the the Layer 2 fabric. This can be circumvented by disabling MLS on your fabric, but will result in all of your packets being process switched, inherently increasing the CPU load of your MSFC/CPU. Depending on your configuration, your SVI information can be coupled with the Layer 2 SNMP statistics (at least for I/O) to provide more accurate numbers. I apologize if I have missed something, but I'm assuming this is what you're alluding to. Regards, Anthony Cennami Robert A. Hayden wrote: Hey all, This one is a weird one. I apologize if this is a bit off topic. As everyone is probably aware, the Cisco 6500/7600 line is unable to provide per-vlan I/O statistics on routed interfaces (ie, a "show int vlan xxx" has meaningless numbers in the I/O and error fields at the end). MIB tables also fail to provide meaningful data. You CAN get some L2 VLAN data, but that doesn't help you when you need to know what's going through the router interface. We've be going around and around with the vendor for a while now about how this makes it pretty useless for traffic analysis, and even showed them the RFC that requires that the information be made available to call it a router. Their latest tactic is to claim that "nobody else in the industry is concerned about this shortcoming". For us, we've been collecting routed interface stats going back all the way to 1996 and with our new gear we've been sold we find that our graphs are pretty empty and we get no reasonable information about how much traffic is passing through the L3 interfaces. So, here's the question I have for anybody out there dealing with this hardware. Is this shortcoming an issue for how you run your network? Have you asked Cisco to fix it? My feeling is that a lot of people find it to be an issue and simply accept it is yet another broken cisco thing. Please let me know privately. I want to talk into our next meeting with some printed testimonials from "real people" that this box is plain broken. Let me know as well if you don't want me to use your name and/or organization in my report. Thanks for your time. - Robert Hayden University of Wisconsin Madison
Re: RBLs in use
Suresh Ramasubramanian wrote: You need a fairly wide coverage of BLs. # Open proxies - http://opm.blitzed.org and http://proxies.blackholes.easynet.nl I would add the SORBS http and SORBS socks lists to this. # Open relays - http://www.ordb.org I'd add VISI to that too. # Dialup and DSL/cable dynamic IPs - http://dynablock.easynet.nl # Current spam sources - http://cbl.abuseat.org [strongly recommended] CBL tends to list only open proxies and spam trojans, but there's a few "classic viri emitters" (ie: Yaha) and a _very_ small number of "grossly misconfigured mail servers" in it too. All of which you want to know about anyway. What you can do is do zone downloads of the open relay/proxy/CBL lists above and correlate them to your own netblocks. _Very_ helpful in finding compromised systems. With dynablock, you may want to audit it for accuracy against your IP allocations. They're responsive to update requests. SBL/SPEWS identifies your spammers. But as Suresh says, be careful to interpret the SPEWS listings correctly, so you nail the spammer, not the collateral damage. There are a lot more DNSBLs, but the above ones are the most respected, important and useful for your purposes. XBL & Spambag, for example, are too rabid to worry about. Anybody who uses them gets what they deserve.
Re: IPSEC VPNs capable of handling worm traffic
At 06:27 PM 11/19/2003, Magnus Eriksson wrote: >The last 2 days I've been fighting against the Nachi ICMP onslaght on a customer >network. Have you tried rate-limiting or blocking ICMP echo/echo/reply messages? Worm traffic will typically follow the default route to the FW for prefixes that are not in your routing table. It can help the backbone if you null-route your aggregates while permitting traffic to flow to known more-specific prefixes that are in the RT. >Problem is that the "random" destination traffic seem to kill my VPNs by vendor N. >CPU is consumed, probably due to trying to maintain/update route cache. Or maybe it >hits it's pps limit. Hard to say based on the info provided.Cache churn could be part of your problem as could CPU use do the creating of cache entires. It doesn't take any infected PC's to bring a cache based system to it's knees. >Ordinary traffic req. is approx. 10 Mbit/s mixed traffic. >Worm traffic I would like to be able to handle is approx 2-3kpps. > >Anyone know of any VPN boxes/routers with VPN capability that is better able to >handle the onslaught? IOS should be able to handle this. CEF, which is not cache based, is strongly recommend. It will switch the packets normally at high speeds w/o the extra CPU associated with cache creating/deletion. You will need to make sure that b/w and IPSEC crypto performance isn't a limiting factor as well. Most folks identify infected hosts by Netflow, IDS, etc. Once identified, these hosts are denied access to the network using AAA, DHCP, ACL's (as applicable) until such time as the worm has been shown to be mitigated. PBR can also be used to divert the ICMP traffic to someplace where it can be Snifed and analyzed, etc. There is more info on mitigation on the Cisco web site. http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a00801b143a.shtml Regards, Bruce >Is vendors C's boxes better than Nortel's? Is CEF going to help me? Or is the problem >pps related? > >Will it help to throw a bigger box at the problem? > >Any advice greatly appreciated. > >Regards >Magnus - Sweden > > >
Re:
> I am a student doing my Masters thesis. My query is that Someone doing graduate studies in networking should really do some basic research before asking questions on a mailing list. Normally, you start by reviewing the literature. If you had done that you would have discovered that your questions don't have an answer because you are asking the wrong questions. You will also discover that the network operators on this mailing list don't have the kind of answers that you are looking for. I suggest that you spend a few weeks reading papers from http://citeseer.nj.nec.com/cs and also from the homepages of the authors. --Michael Dillon
Per VLAN Stats on MSFC2 - Complaints from the Field
Hey all, This one is a weird one. I apologize if this is a bit off topic. As everyone is probably aware, the Cisco 6500/7600 line is unable to provide per-vlan I/O statistics on routed interfaces (ie, a "show int vlan xxx" has meaningless numbers in the I/O and error fields at the end). MIB tables also fail to provide meaningful data. You CAN get some L2 VLAN data, but that doesn't help you when you need to know what's going through the router interface. We've be going around and around with the vendor for a while now about how this makes it pretty useless for traffic analysis, and even showed them the RFC that requires that the information be made available to call it a router. Their latest tactic is to claim that "nobody else in the industry is concerned about this shortcoming". For us, we've been collecting routed interface stats going back all the way to 1996 and with our new gear we've been sold we find that our graphs are pretty empty and we get no reasonable information about how much traffic is passing through the L3 interfaces. So, here's the question I have for anybody out there dealing with this hardware. Is this shortcoming an issue for how you run your network? Have you asked Cisco to fix it? My feeling is that a lot of people find it to be an issue and simply accept it is yet another broken cisco thing. Please let me know privately. I want to talk into our next meeting with some printed testimonials from "real people" that this box is plain broken. Let me know as well if you don't want me to use your name and/or organization in my report. Thanks for your time. - Robert Hayden University of Wisconsin Madison
Re: RBLs in use
Paul S. Brown writes on 11/20/2003 10:51 AM: For example something like the old Dorkslayers lists should be ignored because they would blacklist you if you sneezed at the wrong time, however MAPS is probably a good list. You need a fairly wide coverage of BLs. # Open proxies - http://opm.blitzed.org and http://proxies.blackholes.easynet.nl # Open relays - http://www.ordb.org # Dialup and DSL/cable dynamic IPs - http://dynablock.easynet.nl # Current spam sources - http://cbl.abuseat.org [strongly recommended] # Direct spam sources - SBL (http://www.spamhaus.org) and possibly spews.org as well, though spews tends to produce a lot of collateral damage by design. SBL is a lot more surgical. srs -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
Re: RBLs in use
I run the Abusive Hosts Blocking List (http://www.ahbl.org). We list everything from spam sources, to spam supporters, open proxies, open relays, drones, etc. Its in use on all of the mail servers I help administrate (which includes several fortune 500 companies, half a dozen regional ISPs, and several .edu sites), plus SpamHaus, SpamCop BL, SORBS, EasyNet, and several others, which help balance out protection. A good list of all known ones is up at: http://www.declude.com/junkmail/support/ip4r.htm The only DNSbl which you really should avoid like the plague is the XBL (which I believe is gone at this point). In the various places where I've gotten a look at their spam protection, SpamHaus is very popular, as is SpamCop's BL. -- Brian Bruns The Summit Open Source Development Group Open Solutions For A Closed World / Anti-Spam Resources http://www.sosdg.org The AHBL - http://www.ahbl.org - Original Message - From: "Paul S. Brown" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, November 20, 2003 10:16 AM Subject: RBLs in use > > I have been asked to find out what DNSBLs are in use so my employer can see > what the incidence of its being blacklisted is and how much impact this is > likely to have had on their business. > > What DNSBLs are being used by the various agencies represented on NANOG and > how much weighting do you give them. Are there any DNSBLs you would > completely ignore due to data quality issues? > > Thanks > > Paul >
Re: RBLs in use
Nope, Just an ISP with normal ISP type operational spam problems. I'm trying to quantify how often we actually appear on RBL, but I want to get some idea of how much credence to give to appearing on any given list. For example something like the old Dorkslayers lists should be ignored because they would blacklist you if you sneezed at the wrong time, however MAPS is probably a good list. P. On Thursday 20 November 2003 3:33 pm, todd glassey wrote: > Does this mean that your employer is a spam operator? > > T > - Original Message - > From: "Paul S. Brown" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, November 20, 2003 7:16 AM > Subject: RBLs in use > > > I have been asked to find out what DNSBLs are in use so my employer can > > see > > > what the incidence of its being blacklisted is and how much impact this > > is likely to have had on their business. > > > > What DNSBLs are being used by the various agencies represented on NANOG > > and > > > how much weighting do you give them. Are there any DNSBLs you would > > completely ignore due to data quality issues? > > > > Thanks > > > > Paul
Re: IPSEC VPNs capable of handling worm traffic
All of these cute references to "vendor c" and "vendor n" go by the wayside when we slip and say "Nortel" or refer to "CEF". :) IMHO, if you aren't breaking an NDA, you might as well name names. If you are breaking an NDA, using initials won't screen you from legal jeopardy... - Daniel Golding On 11/19/03 6:27 PM, "Magnus Eriksson" <[EMAIL PROTECTED]> wrote: > > The last 2 days I've been fighting against the Nachi ICMP onslaght on a > customer network. > > Problem is that the "random" destination traffic seem to kill my VPNs by > vendor N. CPU is consumed, probably due to trying to maintain/update > route cache. Or maybe it hits it's pps limit. > > Ordinary traffic req. is approx. 10 Mbit/s mixed traffic. > Worm traffic I would like to be able to handle is approx 2-3kpps. > > Anyone know of any VPN boxes/routers with VPN capability that is better > able to handle the onslaught? Is vendors C's boxes better than Nortel's? > Is CEF going to help me? Or is the problem pps related? > > Will it help to throw a bigger box at the problem? > > Any advice greatly appreciated. > > Regards > Magnus - Sweden > > > >
Re: RBLs in use
Does this mean that your employer is a spam operator? T - Original Message - From: "Paul S. Brown" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, November 20, 2003 7:16 AM Subject: RBLs in use > > I have been asked to find out what DNSBLs are in use so my employer can see > what the incidence of its being blacklisted is and how much impact this is > likely to have had on their business. > > What DNSBLs are being used by the various agencies represented on NANOG and > how much weighting do you give them. Are there any DNSBLs you would > completely ignore due to data quality issues? > > Thanks > > Paul >
Re: IPSEC VPNs capable of handling worm traffic
On Thu, 20 Nov 2003 00:27:20 +0100, Magnus Eriksson wrote > Will it help to throw a bigger box at the problem? Would help to know what box you're using if you want to know whether a larger box would help. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
[no subject]
Bonjour, I am a student doing my Masters thesis. My query is that 1. what is the way to predict how a traffic will be arriving in router, by having a statistical information of the length of the bursts and the silence. (are there any papers which have worked on it) 2. Is it possible to improve the efficiency of a switching fabric if we know the traffic profile . Thanks Cordialement, Sandoche Balakrichenan. _ Contact brides & grooms FREE! Only on www.shaadi.com. http://www.shaadi.com/ptnr.php?ptnr=hmltag Register now!
RBLs in use
I have been asked to find out what DNSBLs are in use so my employer can see what the incidence of its being blacklisted is and how much impact this is likely to have had on their business. What DNSBLs are being used by the various agencies represented on NANOG and how much weighting do you give them. Are there any DNSBLs you would completely ignore due to data quality issues? Thanks Paul
DOE report on 08/14 Blackout released (was: Utility Mapping to be featured at the 2003 DPC in Tampa)
Get 'em while they're hot: https://reports.energy.gov/ ---Rob
