RE: What do you want your ISP to block today?
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Gerardo Gregory > > Frankly I dont want any of my ISP's filtering any of my > traffic. I > think we need (especially enterprise administrators like > myself) to take > some responsibility, and place our own filters. That's a popular sentiment which derives its facade of reasonableness from the notion that ISP's ought to provide unencumbered pipes to the Internet core. However, it doesn't bear close scrutiny. Would you say that ISP's should not filter spoofed source addresses? That they should turn off "no ip directed broadcast"? Of course not, because such traffic is clearly pathological with no redeeming social value. The tough part for the ISP is to decide what other traffic types are absolutely illegitimate and should therefore be subject to being Verboten on the net.
Re: On the back of other 'security' posts....
[EMAIL PROTECTED] (Matthew Sullivan) writes: > ..and if the perps are on this list, keep going if you want, the more > you do the more likely you'll get caught. You will not force SORBS off > the net like you have Osirusoft. I and SORBS will leave when we are > good and ready, and not because of some infantile spotty faced 15 year > old nerd without a clue on life. these aren't script kiddies, in fact i don't think they're kids. these seem to be professional spammers whose revenue is being hurt by sorbs. the kids i've talked to think that the blackhole lists are good things, since these kids are usually spam victims and almost never spam perps. -- Paul Vixie
Re: What if it doesn't affect the ISP? (was Re: What do you want your
> Bits are bits, very few of them actually impact the ISP itself. Most Lies! all the bits that pass through the ISP impact the ISP. Generally in the fiscal arena. More bits == More cash. > Or some major ISPs seem to have the practice of letting the infected > computers continuing attacking as long as it doesn't hurt their > network. Or for fiscal reasons... -- bill (being cynical in WDC)
Re: What do you want your ISP to block today?
On Sat, Aug 30, 2003 at 02:53:46PM -0400, [EMAIL PROTECTED] wrote: > On Sat, 30 Aug 2003 14:09:40 EDT, Joe Abley said: > > That won't save them when the time required to download the patch set > > is an order of magnitude greater than the mean time to infection. > > This, in fact, is the single biggest thorn in our side at the moment. It's hard > to adopt a pious "patch your broken box" attitude when the user can't get it > patched without getting 0wned first... how about ACLing them? upstream from customer: permit udp port 53 permit tcp port 80(?) for as much of the windows update range as can be found. Since they've recently akamai'zed, this is somewhat predictable. Downstream, you can either setup stateful, or just be lazy and hope that allowing estab flag is enough... ACL can be either templated or genericized for the OS. (replacing with any means the customer pvc (assuming DSL) can only hit microsoft regardless of spoofing. Similar ACLs can be setup for Solaris, OSX, even various flavors of linux. being able to at least semi-automate router config changes is a requisite, but not insurmountable. This will, no doubt, increase support calls. How much compared to a pervasive work is left as an exercise to the reader. -- Ray Wong [EMAIL PROTECTED]
What if it doesn't affect the ISP? (was Re: What do you want yourISP to block today?)
On Sat, 30 Aug 2003, Iljitsch van Beijnum wrote: > Only if it impacts the ISP, which it doesn't most of the time unless > they buy an unfortunate brand of dial-up concentrators. Bits are bits, very few of them actually impact the ISP itself. Most ISPs protect their own infrastructure. Routers are very good at forwarding bits. Routers have problems filtering bits. Whether it is spam, viruses or other attacks; its mostly customers or end-users that bear the brunt of the impact, not the ISP. The recurring theme is: I don't want my ISP to block anything I do, but ISPs should block other people from doing things I don't think they should do. So how long is reasonable for an ISP to give a customer to fix an infected computer; when you have cases like Slammer where it takes only a few minutes to infect the entire Internet? Do you wait 72 hours? or until the next business day? or block the traffic immediately? Or some major ISPs seem to have the practice of letting the infected computers continuing attacking as long as it doesn't hurt their network.
Re: What do you want your ISP to block today?
On Sat, 30 Aug 2003 14:09:40 EDT, Joe Abley said: > That won't save them when the time required to download the patch set > is an order of magnitude greater than the mean time to infection. This, in fact, is the single biggest thorn in our side at the moment. It's hard to adopt a pious "patch your broken box" attitude when the user can't get it patched without getting 0wned first... > Seems to me that it would be far more effective to simply prohibit > connection of machines without acceptable operating systems to the > network. That would send a more appropriate message to the vendor, too > (better than "don't bother to test before you release, we'll pay to > clean up the resulting mess"). Given the Lion worm that hit Linux boxes, and the fact there's apparently a known remote-root (since fixed) for Apple's OSX, what operating systems would you consider "acceptable"? pgp0.pgp Description: PGP signature
RE: On the back of other 'security' posts....
Owen DeLong wrote:
> The ISPs aren't who should be sued. The people running
> vulnerable systems generating the DDOS traffic and the
> company providing the Exploding Pinto should be sued. An
> ISPs job is to forward IP traffic on a best effort basis to
> the destination address contained in the header of the
> datagram. Any other behavior can be construed as a breach of
> contract. Sure, blocking spoofed traffic in the limited
> cases where it is feasible at the edge would be a good thing,
> but, I don't see failure to do so as negligent.
In what instances is blocking spoofed traffic at the edge not feasible?
("Spoofed" as in not sourced from one of the customer's netblocks.)
> Where exactly do you think that the duty to care in this
> matter would come from for said ISP?
Isn't the edge by far the easiest and most logical place to filter
spoofed packets? What are the good reasons not to do so?
> Again, I just don't see where an ISP can or should be held
> liable for forwarding what appears to be a correctly
> formatted datagram with a valid destination address.
I guess "correctly formatted" is a relative term. When *isn't* a packet
with a spoofed source IP address guaranteed to be illegitimate? Maybe
such packets shouldn't be considered "correct".
> This is the desired behavior and without it, the internet
> stops working.
The Internet stops working when legitimate packets aren't forwarded.
Spoofed packets don't fall into this category.
> The problem is systems with consistent and
> persistent vulnerabilities. One software company is
> responsible for most of these, and, that would be the best
> place to concentrate any litigation aimed at fixing the
> problem through liquidated damages.
I don't think it's appropriate to point the finger at one entity here.
Lots of folks can play a part in helping out with this problem. That
spoofed packets often originate from compromised hosts running Microsoft
software doesn't justify ISPs standing around with their hands in their
pockets if there are reasonably simple measures they can take to prevent
such packets from ever getting past their edge routers. If edge
filtering isn't considered a "reasonably simple" thing to do, I'd like
to hear the reasons why.
-Terry
Re: What do you want your ISP to block today?
On zaterdag, aug 30, 2003, at 18:54 Europe/Amsterdam, Owen DeLong wrote: Christopher L. Morrow's mention of asymmetric routing for multihomed customers is more to the point, but if we can solve this for all those single homed dial, cable and ADSL end-users and not for multihomed networks, I'll be very happy. I happen to look alot like a single homed ADSL end user at certain levels, but, I'm multihomed. I'd be very annoyed if my ISP started blocking things just because my traffic pattern didn't look like what they expect from a single homed customer. I'm sure knife salespeople find it extremely annoying that they can't bring their wares along as carry-on when they fly. Sometimes a few people have to be inconvenienced for the greater good. But, TCP to a port that isn't listening (or several ports that aren't listening) _ARE_ what you are talking about blocking. This is not a good idea. Why not? I think it's a very good idea. TCP doesn't work if you only use it in one direction, so blocking this doesn't break anything legitimate, but it does stop a whole lot of abuse. (Obviously I'm talking about the case where the lack of return traffic can be determined with a modicum of reliability.) It should be possible to have a host generate special "return traffic" that makes sure that stuff that would otherwise be blocked is allowed through. I don't think it's desirable or appropriate to have everyone re-engineer their hosts to allow monitoring and external validation scans to get around your scheme for turning off services ISPs should be providing. But then you don't seem to have any problems with letting through denial of service attacks so I'm not sure if there is any use in even discussing this with you. Today, about half of all mail is spam, and it's only getting worse. If we do nothing, tomorrow half of all network traffic could be worms, scans and DOS. We can't go on sitting on our hands.
Re: On the back of other 'security' posts....
On Sat, 30 Aug 2003 17:36 UTC Jack Bates <[EMAIL PROTECTED]> wrote: | The person responsible is the bot maintainer. Finding the controller | medium (probably irc) is the hard part, but once done, monitoring who | controls the bots isn't near as hard. For various values of "control". In the cases where we've tracked down bot-masters, they have themselves been throw-away trojaned machines in countries like Taiwan, Korea, etc. The bots found their master through DNS - and the person controlling the DNS had effective control of the botnetwork. If the trojaned site was taken down or tampered with, the human controller would just point the DNS at a different trojaned box. In those cases. the most valuable evidence can therefore be got just by seeing who makes the changes to the DNS for the domain being used. (Of course, different bot-maintainers will have different approaches; I'm not suggesting this is the only system out there!) Co-operation from the LE authorities in the country involved would be a prerequisite to tracking which machines connected to that botmaster and I'm sure the trojaned boxes used were chosen with thought for the likely level of co-operation from the country they were in! | A few media enriched prison sentences would be good. Some interest from law enforcement authorities in "friendly" countries (like, the ones we live and work in) would be a good way to start. More commonly they won't get involved because it's too difficult, plus they don't understand the technology properly, they're under-resourced (particularly in terms of handling the international relationships) and there are no guarantees of brownie-points from the effort anyway! Without law-enforcement interest and adduceable evidence you don't get any prosecutions, and without prosecutions you don't get any prison sentences, media-enriched or otherwise. It's a hard world (for us). -- Richard Cox RC1500-RIPE %% HELO - the first word of every Email transaction - is in Welsh! %%
Re: What do you want your ISP to block today?
On Saturday, Aug 30, 2003, at 01:58 Canada/Eastern, Matthew S. Hallacy wrote: On Fri, Aug 29, 2003 at 11:42:16PM -0400, Sean Donelan wrote: North Texas charges students $30 if their computer is infected, and needs to be cleaned. Excellent, perhaps they'll learn early that they have to patch often. That won't save them when the time required to download the patch set is an order of magnitude greater than the mean time to infection. Seems to me that it would be far more effective to simply prohibit connection of machines without acceptable operating systems to the network. That would send a more appropriate message to the vendor, too (better than "don't bother to test before you release, we'll pay to clean up the resulting mess"). Joe
Re: On the back of other 'security' posts....
Owen DeLong wrote: Again, I just don't see where an ISP can or should be held liable for forwarding what appears to be a correctly formatted datagram with a valid destination address. This is the desired behavior and without it, the internet stops working. The problem is systems with consistent and persistent vulnerabilities. One software company is responsible for most of these, and, that would be the best place to concentrate any litigation aimed at fixing the problem through liquidated damages. Most dDOS's come from bots. Bots are installed on all operating systems and all architectures. I'd be surprised if the packets are all spoofed. In most dDOS cases these days, they are real IP's and just a high number of bots. The person responsible is the bot maintainer. Finding the controller medium (probably irc) is the hard part, but once done, monitoring who controls the bots isn't near as hard. Tracking them down can be abit of fun, but usually they get lazy about covering tracks at that point. A few media enriched prison sentences would be good. -Jack
Re: On the back of other 'security' posts....
Yet more spoofed traffic aimed at the SORBS nameservers - this time enough to crash a core router of my upstream... Hopefully the commercial damage now may insite people getting damaged by these DDoSes to start proceedings against those ISPs whom continue to show a lack of respobsibility and allow unfiltered spoofed DDoS traffic from their networks. Certainly I have been told to talk to various US authorities about the problem, and will be doing so as soon as I have the nessesary information. The ISPs aren't who should be sued. The people running vulnerable systems generating the DDOS traffic and the company providing the Exploding Pinto should be sued. An ISPs job is to forward IP traffic on a best effort basis to the destination address contained in the header of the datagram. Any other behavior can be construed as a breach of contract. Sure, blocking spoofed traffic in the limited cases where it is feasible at the edge would be a good thing, but, I don't see failure to do so as negligent. Where exactly do you think that the duty to care in this matter would come from for said ISP? In the mean time a plea to people on this list in all countries - watch for the DDoS attacks (particually against 203.15.51.33, 203.15.51.35, 203.15.51.44 & 203.101.254.254) and stop the damn traffic before you are held responsible for your customers actions. There is still a 10k pps SYN flood occuring 8 hours later - this is being rate limited upstream. Again, I just don't see where an ISP can or should be held liable for forwarding what appears to be a correctly formatted datagram with a valid destination address. This is the desired behavior and without it, the internet stops working. The problem is systems with consistent and persistent vulnerabilities. One software company is responsible for most of these, and, that would be the best place to concentrate any litigation aimed at fixing the problem through liquidated damages. Owen
Re: What do you want your ISP to block today?
Christopher L. Morrow's mention of asymmetric routing for multihomed customers is more to the point, but if we can solve this for all those single homed dial, cable and ADSL end-users and not for multihomed networks, I'll be very happy. Sorry to throw yet another insect into the topical remedy (fly in the ointment), but, I happen to look alot like a single homed ADSL end user at certain levels, but, I'm multihomed. I'd be very annoyed if my ISP started blocking things just because my traffic pattern didn't look like what they expect from a single homed customer. So which do you prefer: nobody gets to scan your systems from the outside (including you) or everyone gets to scan your systems from the outside (including you). I prefer the latter. If you want to know how TCP is working to a destination, you have to use TCP to test it. As I mentioned above: this will not impact TCP at all because TCP generates return traffic. I'm sure there are one or two UDP applications out there that don't generate return traffic, but I don't know any. The only problem (except asymmetric routing when multihomed) would be tunnels, but you can simply enable RIP or something else on the tunnel to make sure it's used in both directions. Multicast doesn't generate return traffic so this would only apply to unicast destinations. But, TCP to a port that isn't listening (or several ports that aren't listening) _ARE_ what you are talking about blocking. This is not a good idea. Scans by themselves certainly aren't inherently dangerous. It should be possible to have a host generate special "return traffic" that makes sure that stuff that would otherwise be blocked is allowed through. I don't think it's desirable or appropriate to have everyone re-engineer their hosts to allow monitoring and external validation scans to get around your scheme for turning off services ISPs should be providing. Owen
Re: Automatic shutdown of infected network connections
Sean Donelan wrote: How many ISPs disconnect infected computers from the network? Do you leave them connected because they are paying customers, and how else could they download the patch from microsoft? We disconnect after contact if they remain infected after 72 hours or once we determine contact won't be possible. User's are responsible for their own computers. We understand that many of them need the service in order to fix their systems. However, a line has to be drawn at some point. I want the 135 blocks removed, and in order to do that, the malicious packets must be reduced to a minimum. -Jack
Re: What do you want your ISP to block today?
Sean Donelan wrote: If you don't want to download patches from Microsoft, and don't want to pay McAfee, Symantec, etc for anti-virus software; should ISPs start charging people clean up fees when their computers get infected? www.google.com +Free +AntiVirus Now was that so hard? -Jack
Re: What do you want your ISP to block today?
Rob Thomas wrote: Oh, good gravy! I have a news flash for all of you "security experts" out there: The Internet is not one, big, coordinated firewall with a handy GUI, waiting for you to provide the filtering rules. How many of you "experts" regularly sniff OC-48 and OC-192 backbones for all those naughty packets? Do you really want ISPs to filter the mother of all ports-of-pain, TCP 80? Yes. While I hate to admit it, the one thing worse than not applying filters is applying them incorrectly. A good example would be the icmp rate limits. It's one thing to shut off icmp, or even filtering 92 byte icmp. The second one rate-limits icmp echo/reply, they just destroyed the number one network troubleshooting and performance testing tool. If it was a full block, one would say "it's filtered". Yet with rate limiting, you just see sporatic results; sometimes good, sometimes high latency, sometimes dropped. Filter edges, and if you apply a backbone filter, apply it CORRECTLY! Rate-limiting icmp is not correctly. -Jack
Re: dry pair
Dan Hollis wrote: On Fri, 29 Aug 2003, Wayne wrote: if you can get a sales rep to sell it to you, getting it repaired when it fails will be quite a challenge. Seems like business DSL would be less headache in the long run. it "seems" like it would, but thats not the case. our lads circuits stay up for years straight 24/7, while the ilec dsl Luckily you seem to have avoided any "John Deere Cable Sniffers" for an extended period of time. :-) network shits itself silly every couple months. Perhaps a different DSL provider? -Dan You make a valid point: why fix something that isn't broken (yet). You apparently already accomplished what I would view as the hardest part of this solution--the successful ordering and installation of the service. -- Wayne Gustavus --
Re: What do you want your ISP to block today?
On Sat, 30 Aug 2003 13:44:05 +0100 Ian Mason <[EMAIL PROTECTED]> wrote: > > At 07:33 30/08/2003, Iljitsch van Beijnum wrote: > > >On zaterdag, aug 30, 2003, at 05:42 Europe/Amsterdam, Sean Donelan wrote: > > > >>If you don't want to download patches from Microsoft, and don't want to > >>pay McAfee, Symantec, etc for anti-virus software; should ISPs start > >>charging people clean up fees when their computers get infected? > > > >Only if it impacts the ISP, which it doesn't most of the time unless they > >buy an unfortunate brand of dial-up concentrators. > > > >>Would you pay an extra $50/Mb a month for your ISP to operate a firewall > >>and scan your traffic for you? > > > >No way. They have no business even looking at my traffic, let alone > >filtering it. > > > >What would be great though is a system where there is an automatic check > >to see if there is any return traffic for what a customer sends out. If > >someone keeps sending traffic to the same destination without anything > >coming back, 99% chance that this is a denial of service attack. If > >someone sends traffic to very many destinations and in more than 50 or 75 > >% of the cases nothing comes back or just an ICMP port unreachable or TCP > >RST, 99% chance that this is a scan of some sort. > > This is fine until a customers sends out legitimate multicast traffic, so > any such scheme has to ignore multicast traffic. Then the worms and virus > writers will just switch to using multicast as a vector. > It's not just UDP Multicast. Unicast streaming is moving towards UDP. In Apple Darwin Streaming Server, for example, unicast streaming is UDP by default. Examination of my DSS server logs shows that over 2/3 of our video streaming in the last 2 months is over UDP. In this UDP streaming there is return traffic but it is highly assymetric. Regards Marshall Eubanks > Also this only works where routing is strictly symmetrical (e.g. edge > connections, and to single homed edges at that). > > It also has the problem that you have to retain some state (possibly > little) for all outbound traffic until you can match it to inbound traffic. > Given the paupacity of memory in most edge routers this is a problem. Even > with a decent amount of memory, it would soon get overrun, even on a > slowish circuit like a T1. A DSLAM with several hundred DSL lines would > need lots of memory to implement this, and lots of CPU cycles to manage it. > > At the layer 3 level, all TCP traffic is revertive as it has to send ACKs > back so this scheme can't simply work on '"I've seen another packet in the > reverse direction, so it's OK". So we have to work on byte counts and see > if what goes one way is balanced by what goes another way. > > Then it gets worse still, much legitimate traffic is highly asymmetric. In > a POP3 session, most traffic is one way and only a small quantity of high > level ACKs go the other way. Ditto SMTP and most HTTP traffic. > > So, we're reached the stage that, for this to work, it has to have at least > the complexity of a stateful firewall. OK, that is doable, at a cost. But > in the process we seem to have lost any characteristic of asymmetry that > allows us to distinguish good from bad traffic. >
Re: What do you want your ISP to block today?
On zaterdag, aug 30, 2003, at 14:44 Europe/Amsterdam, Ian Mason wrote: What would be great though is a system where there is an automatic check to see if there is any return traffic for what a customer sends out. If someone keeps sending traffic to the same destination without anything coming back, 99% chance that this is a denial of service attack This is fine until a customers sends out legitimate multicast traffic, so any such scheme has to ignore multicast traffic. Then the worms and virus writers will just switch to using multicast as a vector. Yes, that would be cool. I'm surprised that Microsoft doesn't send out its updates over multicast yet. That would save them unbelievable amounts of bandwidth: all Windows boxes simply join the windows update multicast group so they automatically receive each and every update. But we can safely assume they won't use single source multicast so it's only a question of time before some industrious worm builder creates the ultimate worm: one that infects all windows systems world wide by sending a single packet to the windows update multicast group... Ok, this could happen if: 1. more than five people world wide had interdomain multicast capability 2. anyone with multicast capability could send to any multicast group And besides, this will happen if possible regardless of the utility of unicast for worm propagation. Also this only works where routing is strictly symmetrical (e.g. edge connections, and to single homed edges at that). Yes. It also has the problem that you have to retain some state (possibly little) for all outbound traffic until you can match it to inbound traffic. Given the paupacity of memory in most edge routers this is a problem. Even with a decent amount of memory, it would soon get overrun, even on a slowish circuit like a T1. A DSLAM with several hundred DSL lines would need lots of memory to implement this, and lots of CPU cycles to manage it. Give implementers a little credit. There is no need to do this for every packet that flows through a box. You can simply sample the traffic at regular intervals and perform the return traffic check for only a small fraction of all traffic. Statistics is on your side here, as with Random Early Detect congestion/queue management, because you automatically see more packets from sources that send out a lot of traffic. At the layer 3 level, all TCP traffic is revertive as it has to send ACKs back so this scheme can't simply work on '"I've seen another packet in the reverse direction, so it's OK". That's exactly why this works: if the other end sends ACKs, then obviously at _some_ level they're willing to talk. So that would indeed be ok. With DOS and scanning this is very different: for many/most/all packets sent by the attacking system, nothing comes back, except maybe a port unreachable or RST.
Re: What do you want your ISP to block today?
Hey, Chris. ] No... I have one T1 to Sprint and one T1 to AT&T, I think my AT&T bill ] will be high this month so I stop sending OUT AT&T and only accept... Yep, this is a very common tactic, for reasons of finance, politics, responsiveness, etc. Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
Re: What do you want your ISP to block today?
>He added that ISPs have the view and ability to prevent en-masse > attacks. "All these attacks traverse their networks before they reach > you and me. If they would simply stop attack traffic that has been > identified and accepted as such, we'd all sleep better," Cooper said. Frankly I dont want any of my ISP's filtering any of my traffic. I think we need (especially enterprise administrators like myself) to take some responsibility, and place our own filters. Filters not only to stop the ingress attack but to also filter our own egress traffic. I have encountered many private administrators who have the mentality that all they need to do is filter the ingress traffic and do not place egress filters on their networks. TSK TSK TSK! Individuals like Rob Thomas, and countless others provide frequently updated Bogon Lists, templates, etc. apply these to your edge. This is your first layer of filtering. Make sure to apply NULL routes to the BOGONS so you block these on the egress. Apply prefix list if you are a BGP speaker (keep that routing table clean), and access list at your ingress point to block any traffic from a BOGON (Bogus!!!) address. Now you are ready for your next filters. Use a chokepoint, and filter now your TCP/UDP ports, or any other protocols you run internally (MS PORTS???). Making an all inclusive filter is the only way to go here. Now keep yourself informed and modify your filters to mitigate attacks, etc. This might not be the easy way (easy way would be to say...Hey ISP it's on you now...Filter this stuff) but it is the only sure way to protect that network you administrate (which is your responsibility not the ISP's). Frankly all I want my ISP to do is to maintain my link with them, provide to me BGP routes, and accept my advertisements. Your BOGONS are easily maintained since once again individuals like Rob Thomas update their templates accordingly (THANKS!!!), and are nice enough to also inform the list of upcoming changes. A big letter "L" should be stamped on anyone's forehead who was allowing ingress traffic on those MS ports (and even more so if they where allowing it to egress also). Microsoft cannot blame the ISP networks for not filtering the ports used by their proprietary protocols. Shame on them, shame on all those that left these ports open on their networks. Even if ISP's would begin filtering (a thought that doesnt make me too happy) I would never trust their filters because I have no control over them. Yes I am that paranoid!!! Gerardo A. Gregory Manager Network Administration and Security 402-970-1463 (Direct) 402-850-4008 (Cell) Affinitas - Latin for "Relationship" Helping Businesses Acquire, Retain, and Cultivate Customers Visit us at http://www.affinitas.net
Re: Fun new policy at AOL
On Sat, Aug 30, 2003 at 12:21:02PM +0100, Stephen J. Wilcox wrote: > It really doesnt make any difference, if you change the rules by implementing > auth etc the spammers will just adopt and it follows that the more thorough you > are in the anti-spam measures, the more drastic the spammers will become to > maintain their business.. Yes, it does make a difference. a) Now, there is no longer a gray area with spam, if they are successfully bruteforcing your users' passwords, I believe that falls under unauthorized entry (now, there is no need to go to your senator to ASK them to put anti-spam laws in place), and you can follow this up with your local law enforcement agency. b) This adds an extra step, therefore slowing down their dictionary attacks and relay abuse, resulting in a lot LESS spam. c) I'm also asking for server-to-server authentication among trusted mail servers and administrators, at which point you can ask the other mail server to sign a contract laying out the terms of sending mail to your server (and they can do the same to you) and make them legally liable for any breaches. Hey, now you can actally implement those per message fines in all of your AUPs. d) After reptitive breaches, I'm sure users and administrators would be willing to chip into a lawyer pot (kinda like ISPC) which would make it easier to sue offenders rather than asking themselves "is it really worth it to plunk down $10k for some penis enlargement mail". Think of something along the lines of USENET peering, but now with SMTP.
Re: What do you want your ISP to block today?
At 07:33 30/08/2003, Iljitsch van Beijnum wrote: On zaterdag, aug 30, 2003, at 05:42 Europe/Amsterdam, Sean Donelan wrote: If you don't want to download patches from Microsoft, and don't want to pay McAfee, Symantec, etc for anti-virus software; should ISPs start charging people clean up fees when their computers get infected? Only if it impacts the ISP, which it doesn't most of the time unless they buy an unfortunate brand of dial-up concentrators. Would you pay an extra $50/Mb a month for your ISP to operate a firewall and scan your traffic for you? No way. They have no business even looking at my traffic, let alone filtering it. What would be great though is a system where there is an automatic check to see if there is any return traffic for what a customer sends out. If someone keeps sending traffic to the same destination without anything coming back, 99% chance that this is a denial of service attack. If someone sends traffic to very many destinations and in more than 50 or 75 % of the cases nothing comes back or just an ICMP port unreachable or TCP RST, 99% chance that this is a scan of some sort. This is fine until a customers sends out legitimate multicast traffic, so any such scheme has to ignore multicast traffic. Then the worms and virus writers will just switch to using multicast as a vector. Also this only works where routing is strictly symmetrical (e.g. edge connections, and to single homed edges at that). It also has the problem that you have to retain some state (possibly little) for all outbound traffic until you can match it to inbound traffic. Given the paupacity of memory in most edge routers this is a problem. Even with a decent amount of memory, it would soon get overrun, even on a slowish circuit like a T1. A DSLAM with several hundred DSL lines would need lots of memory to implement this, and lots of CPU cycles to manage it. At the layer 3 level, all TCP traffic is revertive as it has to send ACKs back so this scheme can't simply work on '"I've seen another packet in the reverse direction, so it's OK". So we have to work on byte counts and see if what goes one way is balanced by what goes another way. Then it gets worse still, much legitimate traffic is highly asymmetric. In a POP3 session, most traffic is one way and only a small quantity of high level ACKs go the other way. Ditto SMTP and most HTTP traffic. So, we're reached the stage that, for this to work, it has to have at least the complexity of a stateful firewall. OK, that is doable, at a cost. But in the process we seem to have lost any characteristic of asymmetry that allows us to distinguish good from bad traffic.
Re: On the back of other 'security' posts....
On Sat, Aug 30, 2003 at 08:17:39PM +1000, Matthew Sullivan wrote: > > Hi All, > > On the back of the latest round of security related posts, anyone notice > the 50% packet loss (as reported to me) across the USA -> NZ links > around lunchtime (GMT+10) today? Yep, easily .. we saw big routing problems for that /19 and a lot of innocent bystanders, in two waves, correlated across most sources. First signs of trouble at 23:12 GMT. Then long periods of unreachability, from roughly 23:15-23:42 GMT and 01:26-02:10 GMT (the second one less well-correlated; routes were still available from some of our peers). Routes were fully restored globally by 02:12 GMT, presumably after the upstream rate limiting kicked in. If anyone has mrtg plots for the affected links, I'd sure like to see 'em. -- James Cowie Renesys Corporation [EMAIL PROTECTED]
Re: Fun new policy at AOL
On Fri, 29 Aug 2003, Omachonu Ogali wrote: > On Fri, Aug 29, 2003 at 04:08:52PM -0400, Vivien M. wrote: > > If this solution had been implemented 5 years ago instead of the "no third > > party relays" system now in place, I wouldn't be opposed to it... But the > > issue is that the "use the local SMTP server to send" model is the main one > > deployed in the field today, and if you start staying NOW that mail must be > > relayed through a domain's particular SMTP server and that server doesn't > > support SMTP AUTH relaying, you're now screwed... > > If spam was as rampant 5 years ago, perhaps this would be in place. > > Change sucks, doesn't it. It really doesnt make any difference, if you change the rules by implementing auth etc the spammers will just adopt and it follows that the more thorough you are in the anti-spam measures, the more drastic the spammers will become to maintain their business.. Steve
Re: What do you want your ISP to block today?
On zaterdag, aug 30, 2003, at 10:57 Europe/Amsterdam, Ray wrote: So? SMTP uses TCP, TCP generates incoming ACKs for outgoing data, so no problems there. Ah, so you're only looking to stop non-TCP attacks. How long do you think before the majority of DOS are TCP based? SYN floods result in ACKs, they just also result in the server being useless. If an ACK is all you need, you won't catch much of anything. A SYN flood will either stay within the resource limits of the (network to the) target host, or it won't, and either the source addresses are legitimate, or they aren't. Only in one of the four combined cases there will be return traffic for most packets. So this should have beneficial effects most of the time. Also, when the target host implements filtering there won't be return traffic so then it should work even better. Now that it's clear, how about a more obvious one: Streaming services are primarily assymetric, and plenty of them use UDP. There may be a little return traffic, but nothing you're going to predict. I did a little test using Quicktime and I see 10 packets per second return traffic. But the port numbers don't match the traffic flowing in the other direction... The amount of return traffic isn't important, as long as there is _some_. If you want to know how TCP is working to a destination, you have to use TCP to test it. It's an example. I need to generate traffic to the various ports. Even if I know ping is working, that doesn't mean I know HTTP or SSH or RTSP or SMTP are getting through. So what's the problem? You open an HTTP, SSH, RTSP or SMTP session and see if you get a response. If you do, no problems. If you don't, the "suspicious traffic going on" counter increases. If you keep hammering on a non responsive server then after a while something is going to happen to your port. I think rate limiting outgoing traffic to very low levels (5 kbps or so) is probably the best automated way to handle this. Scans by themselves certainly aren't inherently dangerous. It should be possible to have a host generate special "return traffic" that makes sure that stuff that would otherwise be blocked is allowed through. Sure, and spoofing the special "return traffic" will be obvious only to the other end, not the transits in the middle. Hm, good point. Maybe it's easier to set the thresholds such that some limited port scanning doesn't trigger any action. It's not like any of this is going to make targeted portscanning completely impossible anyway, it will mostly make sweeping the net for vulnerable systems too slow to be useful.
On the back of other 'security' posts....
Hi All, On the back of the latest round of security related posts, anyone notice the 50% packet loss (as reported to me) across the USA -> NZ links around lunchtime (GMT+10) today? Yet more spoofed traffic aimed at the SORBS nameservers - this time enough to crash a core router of my upstream... Hopefully the commercial damage now may insite people getting damaged by these DDoSes to start proceedings against those ISPs whom continue to show a lack of respobsibility and allow unfiltered spoofed DDoS traffic from their networks. Certainly I have been told to talk to various US authorities about the problem, and will be doing so as soon as I have the nessesary information. In the mean time a plea to people on this list in all countries - watch for the DDoS attacks (particually against 203.15.51.33, 203.15.51.35, 203.15.51.44 & 203.101.254.254) and stop the damn traffic before you are held responsible for your customers actions. There is still a 10k pps SYN flood occuring 8 hours later - this is being rate limited upstream. ..and if the perps are on this list, keep going if you want, the more you do the more likely you'll get caught. You will not force SORBS off the net like you have Osirusoft. I and SORBS will leave when we are good and ready, and not because of some infantile spotty faced 15 year old nerd without a clue on life. / Mat
Re: What do you want your ISP to block today?
On Sat, Aug 30, 2003 at 10:28:11AM +0200, Iljitsch van Beijnum wrote: > On zaterdag, aug 30, 2003, at 09:54 Europe/Amsterdam, Ray Wong wrote: > So? SMTP uses TCP, TCP generates incoming ACKs for outgoing data, so no > problems there. Ah, so you're only looking to stop non-TCP attacks. How long do you think before the majority of DOS are TCP based? SYN floods result in ACKs, they just also result in the server being useless. If an ACK is all you need, you won't catch much of anything. > Christopher L. Morrow's mention of asymmetric routing for multihomed > customers is more to the point, but if we can solve this for all those > single homed dial, cable and ADSL end-users and not for multihomed > networks, I'll be very happy. Yes, I'd be happy too, but your original point wasn't terribly specific, and doesn't really address typical traffic patterns. Now that it's clear, how about a more obvious one: Streaming services are primarily assymetric, and plenty of them use UDP. There may be a little return traffic, but nothing you're going to predict. I suppose you can call for the end of UDP based streaming protocols. Good luck. It took long enough for people to get used to moving away from NFSv2. > >>attack. If someone sends traffic to very many destinations and in more > >>than 50 or 75 % of the cases nothing comes back or just an ICMP port > >>unreachable or TCP RST, 99% chance that this is a scan of some sort. > > >Sure, and I scan my systems from outside all the time. I'm looking for > >validation that my system has NOT started listening on ports I don't > >run services on. It's called external monitoring, and is rather useful > >in letting me get a good night's sleep. > > So which do you prefer: nobody gets to scan your systems from the > outside (including you) or everyone gets to scan your systems from the > outside (including you). So let's see, my choices are: 1) both cracker and I know if I've been cracked by cracker. 2) cracker knows I've been hacked, I have to wait until my server is now an active participant in screwing the rest of the internet, AND I then have to actively be inspecting the system to see where he's failed to cover his tracks well. Yes, the choice is wonderful. Obscurity has done so much to enhance reliability, security, you name it. > >but I'd still need a way to verify my sites can be reached from other > >places. > > They have something for that now. It's called "ping". Yes, and ICMP echos are already consistent in being blocked (not). This line is relevant: > >If you want to know how TCP is working to a destination, you > >have to use TCP to test it. It's an example. I need to generate traffic to the various ports. Even if I know ping is working, that doesn't mean I know HTTP or SSH or RTSP or SMTP are getting through. Relying on ping to verify outside connectivity is great for providing a ping response server, but not many customers seem interested in paying for that. > As I mentioned above: this will not impact TCP at all because TCP > generates return traffic. I'm sure there are one or two UDP > applications out there that don't generate return traffic, but I don't > know any. The only problem (except asymmetric routing when multihomed) UDP generates return traffic, but there's nothing to predict any degree of symmetry. Indeed, likely different last mile, local congestion, et al virtually guarantee that I can't predict how much return traffic there will be. Look inside, and they all come down to 'push a bunch of UDP out. pray very hard that enough gets to the other side. hope that other side can tell us if not.' ICMP likewise may or may not result in return traffic. At any level, things are almost never completely tit-for-tat. > >Scans by themselves certainly aren't inherently dangerous. > > It should be possible to have a host generate special "return traffic" > that makes sure that stuff that would otherwise be blocked is allowed > through. Sure, and spoofing the special "return traffic" will be obvious only to the other end, not the transits in the middle. -- Ray Wong [EMAIL PROTECTED]
Re: What do you want your ISP to block today?
On zaterdag, aug 30, 2003, at 09:54 Europe/Amsterdam, Ray Wong wrote: What would be great though is a system where there is an automatic check to see if there is any return traffic for what a customer sends out. If someone keeps sending traffic to the same destination without anything coming back, 99% chance that this is a denial of service Eh? Have you ever run a mailing list? No, haven't had the pleasure. The majority of subscribers NEVER post. Those who do, post prior to the large quantity of traffic originates. So? SMTP uses TCP, TCP generates incoming ACKs for outgoing data, so no problems there. Christopher L. Morrow's mention of asymmetric routing for multihomed customers is more to the point, but if we can solve this for all those single homed dial, cable and ADSL end-users and not for multihomed networks, I'll be very happy. attack. If someone sends traffic to very many destinations and in more than 50 or 75 % of the cases nothing comes back or just an ICMP port unreachable or TCP RST, 99% chance that this is a scan of some sort. Sure, and I scan my systems from outside all the time. I'm looking for validation that my system has NOT started listening on ports I don't run services on. It's called external monitoring, and is rather useful in letting me get a good night's sleep. So which do you prefer: nobody gets to scan your systems from the outside (including you) or everyone gets to scan your systems from the outside (including you). but I'd still need a way to verify my sites can be reached from other places. They have something for that now. It's called "ping". If you want to know how TCP is working to a destination, you have to use TCP to test it. As I mentioned above: this will not impact TCP at all because TCP generates return traffic. I'm sure there are one or two UDP applications out there that don't generate return traffic, but I don't know any. The only problem (except asymmetric routing when multihomed) would be tunnels, but you can simply enable RIP or something else on the tunnel to make sure it's used in both directions. Multicast doesn't generate return traffic so this would only apply to unicast destinations. Scans by themselves certainly aren't inherently dangerous. It should be possible to have a host generate special "return traffic" that makes sure that stuff that would otherwise be blocked is allowed through.
Re: What do you want your ISP to block today?
On Sat, Aug 30, 2003 at 08:33:54AM +0200, Iljitsch van Beijnum wrote: > What would be great though is a system where there is an automatic > check to see if there is any return traffic for what a customer sends > out. If someone keeps sending traffic to the same destination without > anything coming back, 99% chance that this is a denial of service Eh? Have you ever run a mailing list? The majority of subscribers NEVER post. Those who do, post prior to the large quantity of traffic originates. I suppose the latter can be accounted for using positronic equipment instead of electronic. =) Legit mailing lists may not be 99% of total traffic, but they're sure a good chunk of legit email. > attack. If someone sends traffic to very many destinations and in more > than 50 or 75 % of the cases nothing comes back or just an ICMP port > unreachable or TCP RST, 99% chance that this is a scan of some sort. Sure, and I scan my systems from outside all the time. I'm looking for validation that my system has NOT started listening on ports I don't run services on. It's called external monitoring, and is rather useful in letting me get a good night's sleep. Could I do it locally? Sure, but I'd still need a way to verify my sites can be reached from other places. If you want to know how TCP is working to a destination, you have to use TCP to test it. When I'm working a half dozen part-time contracts, each of whom has multiple servers scattered around the country, this traffic may well be nearly continuous. My employers will "know" about this (it'll be in some memo that no one read), but I'm not going to find every transit provider I cross to warn them, too much hassle. I'm probably not even going to tell my ISP, as it's none of their business. Are those patterns common among DOS/DDOS? Sure. You'll need to do more analysis than that to determine if that's, in fact, what you have. Scans by themselves certainly aren't inherently dangerous. Heavy levels of them? Well, who gets to define "heavy?" A cracker might need only 2 or 3 scans to get the info needed to attack a site. I probably need a few hundred a day to verify said cracker hasn't succeeded. A script kiddie might run hundreds, or more, or less. -- Ray Wong [EMAIL PROTECTED]
Re: Fun new policy at AOL
On Fri, Aug 29, 2003 at 04:04:42PM -0400, Vivien M. wrote: > You seem to be misunderstanding the issue. Let's say you work at > someplace.edu. You want to send mail from home. With the SPF-type schemes > being discussed, your mail MUST come from someplace.edu's server. > > If someplace.edu won't set up an SMTP AUTH relay, what do you do? Your > dialup account will let you use the dialup ISP's mail server... But your > mail will get bounced because it's not something from someplace.edu. Did I miss the obvious? This is not a technical issue. You have presented a case where one lacks the (free) resources needed to perform one's job. This is something you take up with your manager. "I could easily do this part during my off hours, it just requires the mail server admin to setup (free) SMTP AUTH s/w to limit access to us employees." If not, the company policy is not to do work during off-hours. It can wait until you get in the next business day. (Note that policy here is defined by the actual behavior, not the statement of policy, which can be wrong) > Hence, if no SMTP AUTH relay, you're screwed. Sure. And if they throw the (power) circuit breakers at work, none of my computers work (for long) either. That's not a limitation of the grid. -- Ray Wong [EMAIL PROTECTED]
Re: What do you want your ISP to block today?
On Sat, 30 Aug 2003, Iljitsch van Beijnum wrote: > > What would be great though is a system where there is an automatic > check to see if there is any return traffic for what a customer sends > out. If someone keeps sending traffic to the same destination without > anything coming back, 99% chance that this is a denial of service > attack. If someone sends traffic to very many destinations and in more > than 50 or 75 % of the cases nothing comes back or just an ICMP port > unreachable or TCP RST, 99% chance that this is a scan of some sort. > No... I have one T1 to Sprint and one T1 to AT&T, I think my AT&T bill will be high this month so I stop sending OUT AT&T and only accept traffic, all my traffic in that link... So now I push OUT sprint and IN AT&T. I don't want sprint to kill my connection just because all traffic to me is entering AT&T do I?
Re: What do you want your ISP to block today?
On zaterdag, aug 30, 2003, at 05:42 Europe/Amsterdam, Sean Donelan wrote: If you don't want to download patches from Microsoft, and don't want to pay McAfee, Symantec, etc for anti-virus software; should ISPs start charging people clean up fees when their computers get infected? Only if it impacts the ISP, which it doesn't most of the time unless they buy an unfortunate brand of dial-up concentrators. Would you pay an extra $50/Mb a month for your ISP to operate a firewall and scan your traffic for you? No way. They have no business even looking at my traffic, let alone filtering it. What would be great though is a system where there is an automatic check to see if there is any return traffic for what a customer sends out. If someone keeps sending traffic to the same destination without anything coming back, 99% chance that this is a denial of service attack. If someone sends traffic to very many destinations and in more than 50 or 75 % of the cases nothing comes back or just an ICMP port unreachable or TCP RST, 99% chance that this is a scan of some sort.
Re: What do you want your ISP to block today?
On Fri, Aug 29, 2003 at 11:42:16PM -0400, Sean Donelan wrote: > North Texas charges students $30 if their computer is infected, and needs > to be cleaned. Excellent, perhaps they'll learn early that they have to patch often. > . don't want to > pay McAfee, Symantec, etc for anti-virus software; Please show me an anti-virus product for the desktop that protects against such things, I've disinfected at least 30 machines this week that have McAfee VirusShield or Norton Antivirus installed with automatic updates enabled (and yes, I verified they all had the latest virus definitions), they'll happily sit there spewing shit to the world until they're rebooted (a few weeks later, now that windows will happily kludge along but not completely crash) then you get a wonderful dialog that says: 'Warning $anti-virus-program has found an infected file $FOO but could not delete it' Why couldn't it delete it? Because the file was set read only, and the software is too dumb to attrib -r $file And no, $upstream should not be filtering my connection, if you see activity from my network and I don't respond to a friendly notice, turn off my circuit. -- Matthew S. HallacyFUBAR, LART, BOFH Certified http://www.poptix.net GPG public key 0x01938203
Re: What do you want your ISP to block today?
On Fri, 29 Aug 2003 21:36:36 PDT, Mike Leber said: > Perhaps paper manufacturers should be held liable until they come out with > paper that can't be used to write down bad ideas. Know what *really* irks me? I order blank paper, and this damned company keeps sending me paper that's got connect-the-dots pictures of bad ideas all over it. I'd change vendors, but I can't find a copying machine vendor that will service my copier if I use any other brand pgp0.pgp Description: PGP signature
Re: What do you want your ISP to block today?
On Fri, 29 Aug 2003, Sean Donelan wrote: > http://www.vnunet.com/Analysis/1143268 > > Although companies may have the infrastructure to deal with the current > > band of worms, Trojans and viruses, there is currently a line of defence > > that is not in place. "The problem isn't Microsoft's products or the > > knowledge of the consumer. The problem lies in the ISPs' unwillingness > > to make this issue disappear or at least reduce it dramatically," said > > Cooper. This completely overlooks the user as the ultimate infection vector. Even if Microsoft never has another external hole users can still infect themselves. To paraphrase badly: the most dangerous part of the computer is the nut behind the wheel. Moore's law in on the side of virus writers that spam their viruses to users. As long as users only need to click on email attachments to execute programs you can expect an increasing amount of virus spam. > > He added that ISPs have the view and ability to prevent en-masse > > attacks. "All these attacks traverse their networks before they reach > > you and me. If they would simply stop attack traffic that has been > > identified and accepted as such, we'd all sleep better," Cooper said. Perhaps paper manufacturers should be held liable until they come out with paper that can't be used to write down bad ideas. Mike. +- H U R R I C A N E - E L E C T R I C -+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | [EMAIL PROTECTED] http://www.he.net | +---+
Re: What do you want your ISP to block today?
Hey, Sean. ] North Texas charges students $30 if their computer is infected, and needs ] to be cleaned. I think this is very reasonable, and a great idea. ] Would you pay an extra $50/Mb a month for your ISP to operate a firewall ] and scan your traffic for you? No, but I have been sorely tempted to offer up [coffee|beer|cash] to have ISPs manage the network security of their other customers. :) Folks need to remember that even if they outsource the security facets of their Internet-connected networks, they must still be responsive to abuse complaints and queries. Your managed security services provider might be excellent...or not. In the end it is still YOUR network, and any "CNN moments" will be all YOURS as well. Keep those abuse@ aliases pointed at helpful and clueful folks, and respond as quickly as you would have others respond. Of course if you aren't responsive, you just might end up as an example in my next presentation. ;) Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
Re: Automatic shutdown of infected network connections
On Fri, Aug 29, 2003 at 09:44:11PM -0400, Sean Donelan wrote: > How many ISPs disconnect infected computers from the network? Do you > leave them connected because they are paying customers, and how else > could they download the patch from microsoft? Let's see... * I don't know how many, at minimum, those who receive court subpoenas telling them to. * Do you leave a user connected if they are in violation of your AUP and is wreaking havoc on your network and other networks? * Perhaps you could send a disk out? Or set them up in a sandbox-type LAN where they can only visit your internal disinfection site?
Re: What do you want your ISP to block today?
On Fri, 29 Aug 2003, Rob Thomas wrote: > Filter at the *EDGE* folks. You own your own networks; use and manage > them responsibly. If you need assistance, ASK. If you can't take on > the task, purchase bandwidth from providers who sell (yes, CHARGE YOU > MONEY) a filtering service. North Texas charges students $30 if their computer is infected, and needs to be cleaned. http://www.ntdaily.com/vnews/display.v/ART/2003/08/29/3f4eeca4ac93d If you don't want to download patches from Microsoft, and don't want to pay McAfee, Symantec, etc for anti-virus software; should ISPs start charging people clean up fees when their computers get infected? Would you pay an extra $50/Mb a month for your ISP to operate a firewall and scan your traffic for you?
Re: What do you want your ISP to block today?
Hi, NANOGers. ] > He added that ISPs have the view and ability to prevent en-masse ] > attacks. "All these attacks traverse their networks before they reach ] > you and me. If they would simply stop attack traffic that has been ] > identified and accepted as such, we'd all sleep better," Cooper said. Oh, good gravy! I have a news flash for all of you "security experts" out there: The Internet is not one, big, coordinated firewall with a handy GUI, waiting for you to provide the filtering rules. How many of you "experts" regularly sniff OC-48 and OC-192 backbones for all those naughty packets? Do you really want ISPs to filter the mother of all ports-of-pain, TCP 80? Filter at the *EDGE* folks. You own your own networks; use and manage them responsibly. If you need assistance, ASK. If you can't take on the task, purchase bandwidth from providers who sell (yes, CHARGE YOU MONEY) a filtering service. Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
Re: What do you want your ISP to block today?
On Fri, 29 Aug 2003 18:43:23 PDT, Owen DeLong <[EMAIL PROTECTED]> said: > Um...What exactly is wrong with that? There are lots of LEGAL ways to > download music. And Napster can be used to download non-infringing files. Look where it got them. pgp0.pgp Description: PGP signature
Re: Fun new policy at AOL
On Fri, Aug 29, 2003 at 04:08:52PM -0400, Vivien M. wrote: > If this solution had been implemented 5 years ago instead of the "no third > party relays" system now in place, I wouldn't be opposed to it... But the > issue is that the "use the local SMTP server to send" model is the main one > deployed in the field today, and if you start staying NOW that mail must be > relayed through a domain's particular SMTP server and that server doesn't > support SMTP AUTH relaying, you're now screwed... If spam was as rampant 5 years ago, perhaps this would be in place. Change sucks, doesn't it.
Re: dry pair
On Fri, 29 Aug 2003, Wayne wrote: > if you can get a sales rep to sell it to you, getting it repaired when > it fails will be quite a challenge. Seems like business DSL would be > less headache in the long run. it "seems" like it would, but thats not the case. our lads circuits stay up for years straight 24/7, while the ilec dsl network shits itself silly every couple months. -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]
RE: Fun new policy at AOL
Quoting "Vivien M." <[EMAIL PROTECTED]>: > You seem to be misunderstanding the issue. Let's say you work at > someplace.edu. You want to send mail from home. With the SPF-type schemes > being discussed, your mail MUST come from someplace.edu's server. > > If someplace.edu won't set up an SMTP AUTH relay, what do you do? Your > dialup account will let you use the dialup ISP's mail server... But your > mail will get bounced because it's not something from someplace.edu. > > Hence, if no SMTP AUTH relay, you're screwed. If someplace.edu understands the the basic idea being discussed, one might assume that they wouldn't implement Jim Miller's idea until they've implemented SMTP AUTH (or POP before SMTP) as well. If they don't know about / know how to implement SMTP AUTH, they probably wouldn't bother to make the proper DNS changes to make this idea work. One might also assume that if the MTA used by someplace.edu implements Jim Miller's idea, said MTA is also is modern enough to have support for SMTP AUTH. You may find those to be doubious assumptions, but I don't think they're that unreasonable. The only weakness I see is that spammers could find a domain that doesn't implement Jim Miller's idea and forge mail in their name instead. So what if hotmail.com implements the system? There are 100 million other domain names the spammers could pick from. It's not a solution. It will slow the spammers down. It will inconvenience them. It won't stop them. That doesn't mean it shouldn't be done... just that it's not a panacea, and might not even be that effective. (I wonder if I would get less SPAM if every SMTP server were still an open relay.) By the way, a strengh of this idea that I haven't seen discussed here is that such a system would cut down on the spread (and worthless bounce reports) of current viruses that forge the From: header. -Adam
Re: Fun new policy at AOL
On Fri, Aug 29, 2003 at 02:15:49PM -0400, Matthew Crocker wrote: > SMTP_AUTH authenticated users to a mail server. What I'm talking Postfix will let you do SMTP authentication from one mail server to another, and to address the person who said a school was brute- forced, this is from server to server, not everyday-client to server. If you can't set a secure password on server to server relations (it's not like you need to remember it, generate some random concoction of 1-100 characters and use that as a password). It's like the same thing as setting up a BGP password or a RADIUS secret, once it's set, it's not going to be changed often (or at all), let alone remembered.
Re: dry pair
Austad, Jay wrote: Does anyone know to go about getting Qwest or a CLEC to patch through a dry pair between two buildings connected to the same CO? When I called to order one, no one knew what I was talking about. -jay Most of the other responses have covered the various terms to try when ordering this type of ckt. All I can say is good luck. I did this back in 1994 with some HDSL modems from Pairgain and it worked like a charm. (btw, I got the 2 ckts I needed for the connection by ordering 2 "alarm ckts" and then rewiring the separate jacks into a single jack for the modem) However, this was before the days of mass DSL deployment and CLECs. The local loop is managed a little tighter these days and ILECs are a lot less willing to sell this type of service. As someone else said, even if you can get a sales rep to sell it to you, getting it repaired when it fails will be quite a challenge. Seems like business DSL would be less headache in the long run. -- Wayne Gustavus --
Automatic shutdown of infected network connections
Some universities such as Vanderbilt University are automatically shutting down network ports when they detected signature worm traffic. Almost 25% of the students' computers were detected as infected when they connected to the university network. http://www.vanderbilthustler.com/vnews/display.v/ART/2003/08/29/3f4eb4b3537e0 How many ISPs disconnect infected computers from the network? Do you leave them connected because they are paying customers, and how else could they download the patch from microsoft?
Re: What do you want your ISP to block today?
Um...What exactly is wrong with that? There are lots of LEGAL ways to download music. Apple's Music Store and several other licensed commercial services provide music download services, as well as internet radio and other "fair use" applications. This seems like a perfectly legitimate reason to want internet access. As such, it seems like a perfectly reasonable feature to advertise. The problem _IS_ Micr0$0ft choosing to produce code with vulnerabilities in order to increase market penetration. They have essentially built the information superhighway equivalent of the exploding Pinto and it's high time they got held accountable if you ask me. I hesitate to include this here (sorry Susan), but, I'm starting to think that all the admins and other people who are suffering impact on their non-windows systems from these vulnerabilities generating DOS traffic should take Micr0$0ft to small claims court. Let them defend a couple of million tiny lawsuits all over the world. Make them play whack-a-mole the way we've had to on patching their garbage. Owen --On Friday, August 29, 2003 21:14 -0400 [EMAIL PROTECTED] wrote: On Fri, 29 Aug 2003 21:06:24 EDT, Terry Baranski <[EMAIL PROTECTED]> said: This is a disturbing viewpoint. Next thing you know we'll be blaming ISP's for file sharing... Well, when one of the largest providers of high-speed internet access is including "download music" as a reason for wanting their service.
Re: Blaster author identified, about to be arrested...
Speaking on Deep Background, the Press Secretary whispered: > > > >The FBI has identified a teenager as the author of a damaging virus-like > >infection unleashed on the Internet and plans to arrest him early Friday, a U.S. > >official confirmed Thursday. > > It always worries me when law enforcement send out a press statement > that they are going to arrest a particular individual "in the future". Hey, it's hard enough to schedule the arrests for prime news coverage; you gotta get the news teams in place for the perp. walk, write up the off-the-cuff remarks the lead Feebee is going to read, etc.. -- 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
Re: What do you want your ISP to block today?
On Fri, 29 Aug 2003 21:06:24 EDT, Terry Baranski <[EMAIL PROTECTED]> said: > This is a disturbing viewpoint. Next thing you know we'll be blaming > ISP's for file sharing... Well, when one of the largest providers of high-speed internet access is including "download music" as a reason for wanting their service. pgp0.pgp Description: PGP signature
RE: What do you want your ISP to block today?
> "The problem isn't Microsoft's products or the knowledge > of the consumer. The problem lies in the ISPs' unwillingness > to make this issue disappear or at least reduce it > dramatically," said Cooper. This is a disturbing viewpoint. Next thing you know we'll be blaming ISP's for file sharing... -Terry
What do you want your ISP to block today?
Which Microsoft protocols should ISP's break today? Microsoft Exchange? Microsoft file sharing? Microsoft Plug & Play? Microsoft SQL/MSDE? Microsoft IIS? It would be so much easier if worm writers followed the RFC's and set the Evil Bit. China has firewalled the entire country, and they have more infected computers than the US. http://www.vnunet.com/Analysis/1143268 > Although companies may have the infrastructure to deal with the current > band of worms, Trojans and viruses, there is currently a line of defence > that is not in place. "The problem isn't Microsoft's products or the > knowledge of the consumer. The problem lies in the ISPs' unwillingness > to make this issue disappear or at least reduce it dramatically," said > Cooper. > He added that ISPs have the view and ability to prevent en-masse > attacks. "All these attacks traverse their networks before they reach > you and me. If they would simply stop attack traffic that has been > identified and accepted as such, we'd all sleep better," Cooper said.
RE: dry pair
On Fri, 29 Aug 2003 11:24:35 -0500, Austad, Jay wrote: >I also tried asking for an Alarm Circuit. I even explained to them what it >was, but they still didn't understand. All of the people I talked to >wondered why in the world I would want a pair with no dialtone. This is what happens when you staff your "support" departments with dropouts from McDonalds. They need people who have climbed poles and been down in manholes (among other things). The training is abysmal and management doesn't care. Jeffrey Race
Re: dry pair
At 23:03 29/08/2003, Joel Jaeggli wrote: On Fri, 29 Aug 2003, Patrick Felt wrote: [snip] > If not, > how would the alarm company get the signal pushed through the fiber, and > could that be done with the dsl signal? The alarm companies need to deliver extremely small amounts of data which can range from make or break circuits to 60 300 or 2400bps data for things like building control systems, that's a considerably different problem than try to ram 1-7mb/s through a 25,000 foot long piece of wire. Not necessarily, the bit rate may be higher. Good modern alarms use a cryptographically secured bitstream to provide the anti-tamper part of the line protection. A cryptographically useful message size with a reasonably short delay between 'raise alarm' and 'indicate alarm' requires a fair bit rate.
