Re: I don't need no stinking firewall!
What is nice about load balancers is that if you design your solution correctly, you can scale them in a very nice way. Things like direct server return, where only the requests hit the load balancer, but the replies (which are usually larger) just route back directly to the client can free up resources on the load balancer to handle more complex policies. This also reduces the imposed symmetry for routing that firewalls bring to the table. Further on, if you want to really protect against a real DDoS you would most likely would have to look at a really distributed solution, where the different geographical load balancing solutions come into play. Arie On Wed, Jan 6, 2010 at 7:03 AM, George Bonser gbon...@seven.com wrote: -Original Message- From: Dobbins, Roland [mailto:rdobb...@arbor.net] Sent: Tuesday, January 05, 2010 8:53 PM To: NANOG list Subject: Re: I don't need no stinking firewall! On Jan 6, 2010, at 11:43 AM, George Bonser wrote: Yes, you have to take some of the things that were done in one spot and do them in different locations now, but the results are an amazing increase in service capacity per dollar spent on infrastructure. I strongly agree with the majority of your comments, with the caveat that I've seen many, many load-balancers fall over due to state- exhaustion, too; load-balancers need northbound protection from DDoS (S/RTBH, flow-spec, IDMS, et. al.), as well. Yes, I have seen load balancers fall over, too. I have some interesting stories of how those problems have been solved. Sometimes it relies on using a feature of one vendor to leverage a feature of another vendor. But I generally agree with you. There is a lot that can be done ahead of the load balancers.
Re: I don't need no stinking firewall!
On Jan 8, 2010, at 3:21 PM, Arie Vayner wrote: Further on, if you want to really protect against a real DDoS you would most likely would have to look at a really distributed solution, where the different geographical load balancing solutions come into play. GSLB or whatever we want to call it is extremely useful from a general availability standpoint; however, the attackers can always scale up and really distribute their already-DDoS even further (they learned about routeservers and DNS tinkering years ago). Architecture, visibility, and control are key, as are vendor/customer/peer/upstream/opsec community relationships. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: I don't need no stinking firewall!
All, This thread certainly has been educational, and has changed my perception of what an appropriate outward facing architecture should be. But seldom do I have the luxury of designing this from scratch, and also the networks I administer are small business's. My question is at what size connection does a state table become vulnerable, are we talking 1mb dsl's with a soho firewall? Or as I suspect we are talking about a larger scale? I know there are variables, I am just looking for a rule of thumb. I would not want to recommend a change if it is not warranted. But when fatter and fatter pipes become available at what point would a change be warranted. Thanks Bill Kruchas Dobbins, Roland wrote: On Jan 8, 2010, at 3:21 PM, Arie Vayner wrote: Further on, if you want to really protect against a real DDoS you would most likely would have to look at a really distributed solution, where the different geographical load balancing solutions come into play. GSLB or whatever we want to call it is extremely useful from a general availability standpoint; however, the attackers can always scale up and really distribute their already-DDoS even further (they learned about routeservers and DNS tinkering years ago). Architecture, visibility, and control are key, as are vendor/customer/peer/upstream/opsec community relationships. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: he.net down/slow?
On Thu, Jan 07, 2010 at 06:13:16PM -0500, valdis.kletni...@vt.edu wrote: On Thu, 07 Jan 2010 13:51:41 CST, Brian Johnson said: On 7 Jan 2010, at 18:18, William Pitcock wrote: ...why would you have that on a mailing list post? because the mail server that adds it is too dumb to differentiate between list and direct mail? Bingo! ;) That sort of gratuitous add it to everything because our software is too stupid to sort it out is *this* close to what the legal eagles call overwarning. Just sayin'. (Basically, your site and everybody else's site sticks it on everything, all the recipients just ignore it the same way we almost always ignore Received: headers because they're on every message and very rarely have any useful content - with the end result that if you stick it on a message that *matters*, it will still get ignored) Oh, and is your company ready to indemnify my employer for the costs of destroy all copies of the original message sufficiently thoroughly to prevent recovery by a competent forensics expert? This may include, but not be limited to, the main mail store for 70,000 people, backup tapes, and other mail systems where the data may have been logically deleted but as yet not overwritten. Just sayin'. ;) Valdis: 150,000. Not 70,000. Spread across four machines and eleven partitions and 5 flash partions. Not mentioning the pool of a/v scanners, the quarantine servers, the auth server, the five webmail machines, or the OMR. :- -- Dave - Nobody believed that I could build a space station here. So I built it anyway. It sank into the vortex. So I built another one. It sank into the vortex. The third station burned down, fell over then sank into the vortex. The fourth station just vanished. And the fifth station, THAT stayed!
Re: I don't need no stinking firewall!
On Jan 8, 2010, at 8:22 PM, bill from home wrote: Or as I suspect we are talking about a larger scale? Even an attacker with relatively moderate resources can succeed simply by creating enough well-formed, programatically-generated traffic to 'crowd out' legitimate traffic. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: I don't need no stinking firewall!
Roland, I understand, but at the site we are protecting, at what point is the bottleneck the connection speed, and at what point is the state table the bottle neck. It saves me the following uncomfortable conversation. ME Mr customer, remember that firewall you bought a couple of years ago for . Customer Yes... ME We might better throw it out. And then you can pay me to harden your hosts. Or I could just re cable, and leave it turned on, they would never know (just kidding). And maybe there is no way to tell, but I feel I need to ask the question. Thanks Bill Kruchas Dobbins, Roland wrote: On Jan 8, 2010, at 8:22 PM, bill from home wrote: Or as I suspect we are talking about a larger scale? Even an attacker with relatively moderate resources can succeed simply by creating enough well-formed, programatically-generated traffic to 'crowd out' legitimate traffic. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: I don't need no stinking firewall!
On Jan 8, 2010, at 9:02 PM, bill from home wrote: And maybe there is no way to tell, but I feel I need to ask the question. Situationally-dependent; the only way to really tell, not just theorize, is to test the firewall to destruction during a maintenance window (or one like it, in the lab). --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Experiences with Comcast Ethernet/Transit service
I've found them to be quite sufficient here in the PDX metro area. They support all L2 tunnels, in particular, QnQ which I require. We have diverse paths, multiple strands and multi-colored. We are a bit of a special case as we are serviced by a group that is intended for government and education which gives us pricing breaks. The commercial shots I have out to meet-me POPs are priced diffrently. Their CPE devices are migrating to Cisco ME3400, etc. devices. Their tiered pricing is based on link speed which I'm not necessarily pleased with but they're starting to become more flexible. They aren't currently honoring our P-tags so our locations that may be oversubscribed have difficulty with priority queueing. Their new core in our area is a single C 7.6k. I would rather they moved from their older F Big Iron to a J MX or C GSR, but I'm sure the group that services us is faced with limited resources (ref pricing breaks earlier). The customer portal provides custom/customer views on their Orion instance which I find even more useful than my own Cacti graphs at times. The engineering staff is very accesible (again our group is unique). I'd like to see them put gear in more colos and hotels. Their uptime and reliability from my perspective has been right on target. -b On Thu, Jan 7, 2010 at 11:40 PM, Brent Jones br...@servuhome.net wrote: On Wed, Dec 23, 2009 at 1:10 AM, Brandon Galbraith brandon.galbra...@gmail.com wrote: We're looking at using Comcast's (business) transit and private ethernet services at several client locations and I wanted to see what experiences others have had regarding this. Off-list replies are preferred. Thanks, -brandon -- Brandon Galbraith Mobile: 630.400.6992 This was a timely question, as we've have a GigE fiber line with them for 6 months now. Largely, the link performs at ~999Mbit 99% of the time :) However, we've had two issues with connectivity that seem to originate from their network. The link will show up, but both sides of our fiber will show 0 frames received, and lots of transmit errors. It takes a call into the Comcast NOC each time for them to resolve it, but they've been silent on what may actually be going on. These interruptions last anywhere from 30 minutes, to the last one almost 7 hours (luckily over a weekend). Benefits to this, being Metro Ethernet, they do support tagged VLAN's, so cost to entry is low in terms of equipment and setup/support. Our link goes between downtown Portland, OR, to across the river to East Vancouver and Mill Plain. -- Brent Jones br...@servuhome.net -- Bill Blackford Network Engineer
RE: I don't need no stinking firewall!
On Thu Jan 07, 2010 at 01:04:01PM -0800, Jay Hennigan j...@west.net wrote: Or better: - Allow from anywhere port 80 to server port 1023 established Adding established brings us back to stateful firewall! Not really. It only looks to see if the ACK or RST bits are set. This is different from a stateful firewall which memorizes each outbound packet and checks the return for a match source/destination/sequence. Actually, most firewalls don't check TCP sequence numbers. You are totally correct in that stateless packet filters with established are only looking for TCP bits, but the main difference that stateful firewalls add is watching the TCP state machine. Sequence number watching is a bonus, something you can enable on some firewalls, but most of the common ones don't do it by default. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 j...@opus1.comhttp://www.opus1.com/jms
Re: I don't need no stinking firewall!
On Fri, 08 Jan 2010 08:22:00 EST, bill from home said: My question is at what size connection does a state table become vulnerable, are we talking 1mb dsl's with a soho firewall? Security - you're doing it wrong. ;) The question you *should* be asking yourself is at what size connection am I enough of a network presence that I might attract attention from somebody who might want to attack me? And that depends more on the *type* of presence than the size of the pipe. If you're a small electrical-components design firm that nobody's heard of, the size of your state table is probably moot. One of your users just drew the attention of some random 4chan /b/tard, the size of the state table is again probably moot. ;) But to answer your question - it's so absurdly easy for a competent(*) attacker to saturate any edge connection smaller than a gigabit or so, that 'state table exhaustion' is only *really* an issue if you have a 10G or bigger pipe. (*) There is of course the case of an incompetent attacker who only has a botnet of a few hundred machines, attacking a small pipe. At that point, it's probably a crap shoot - if your firewall falls over, you've been DDoS'ed. But if it doesn't fall over, you'll probably *still* be DDoS'ed because the machines you're protecting fall over... pgpj9NQpfiqdL.pgp Description: PGP signature
Re: I don't need no stinking firewall!
All, This thread certainly has been educational, and has changed my perception of what an appropriate outward facing architecture should be. But seldom do I have the luxury of designing this from scratch, and also the networks I administer are small business's. My question is at what size connection does a state table become vulnerable, are we talking 1mb dsl's with a soho firewall? Or as I suspect we are talking about a larger scale? I know there are variables, I am just looking for a rule of thumb. I would not want to recommend a change if it is not warranted. But when fatter and fatter pipes become available at what point would a change be warranted. For small pipes, a simple DoS is trivial enough to jam up the works without worrying about the state table size. However, that doesn't mean it isn't smart to get a handle on it. The biggest question may be pipe size: this variable controls the total possible PPS that can be tossed at the firewall. If you consider a technology such as 10base-T Ethernet, that's 10 megabits per second. When you add up the IFG, MAC preamble, dest/src, MAC type, payload, and CRC, the smallest Ethernet frame is 84 bytes. 10M/(84*8) = 14880 frames per second. Now let's say you want to block a SYN flood from hitting your server (nobody need tell me that there are obvious problems with this; this is an educational exercise). If your firewall is configured to expire state table entries for partially opened connections after 15 seconds, the speed of ethernet combined with the 15 seconds means you need a table that's 225,000 entries large. But wait. If they're blowing 14880 frames per second at you, that Ethernet's quite full. You're already getting DoS'ed by capacity. Further, what happens when the attack moves to simply fully opening connections? Your state table is tiny for that... I know this is NANOG, and it's network-centric. However, fundamentally, a stateful firewall fuzzes the boundary between network and server. It is taking on some duties that have typically been the responsibility of the server. So I'm going to go off on a tangent and say that it may be useful to consider the state of the art in server technology. A good UNIX implementation (OpenBSD, FreeBSD, maybe Linux ;-) ) will be hardened and further-hardenable against these sorts of attacks. The server *already* has to do things such as tracking SYN's, except that they no longer have to - they can issue cookies back and then simply forget about it. If the cookie is returned in the ACK, then a connection is established. A proper implementation of this means that a server using SYN cookies has an infinitely large SYN queue; packets on the network itself are actually the queue. The technique works and scales at 1Mbps as well as it does at 10Gbps. Putting a stateful firewall in front of that would be dumb; the server is completely capable of coping with the superfluous SYN's in a much more competent manner than the firewall. I won't go into this in more detail. You can look to see what the IRC networks are doing to protect themselves. They're commonly beat up and have learned most of the best defense tricks around. A stateless firewall that can implement filtering policies in silicon is absolutely a fantastic thing to have, especially when faced with a DoS for which you can write rules. Put your servers behind one heck of a good stateless firewall, and run a well-tuned OS. You'll be a lot more DoS-resistant. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: qwest outage no notice
Scott Weeks wrote: Try no notice at all and 4 GigEs of upstream bandwidth down at 1:30am. :-( Honestly, I feel for them. They probably left it up to the account reps, which means the smaller circuits probably got notified and the HUGE wholesale accounts were not. Oh, well. That's why we have redundancy. ;) Jack
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith p...@cisco.com. Routing Table Report 04:00 +10GMT Sat 09 Jan, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary BGP routing table entries examined: 307662 Prefixes after maximum aggregation: 143300 Deaggregation factor: 2.15 Unique aggregates announced to Internet: 151565 Total ASes present in the Internet Routing Table: 33037 Prefixes per ASN: 9.31 Origin-only ASes present in the Internet Routing Table: 28698 Origin ASes announcing only one prefix: 14013 Transit ASes present in the Internet Routing Table:4339 Transit-only ASes present in the Internet Routing Table:103 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 22 Max AS path prepend of ASN ( 9503) 20 Prefixes from unregistered ASNs in the Routing Table: 731 Unregistered ASNs in the Routing Table: 133 Number of 32-bit ASNs allocated by the RIRs:385 Prefixes from 32-bit ASNs in the Routing Table: 335 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:186 Number of addresses announced to Internet: 2169545344 Equivalent to 129 /8s, 80 /16s and 162 /24s Percentage of available address space announced: 58.5 Percentage of allocated address space announced: 66.3 Percentage of available address space allocated: 88.2 Percentage of address space in use by end-sites: 80.7 Total number of prefixes smaller than registry allocations: 148143 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:73972 Total APNIC prefixes after maximum aggregation: 25793 APNIC Deaggregation factor:2.87 Prefixes being announced from the APNIC address blocks: 70662 Unique aggregates announced from the APNIC address blocks:31402 APNIC Region origin ASes present in the Internet Routing Table:3913 APNIC Prefixes per ASN: 18.06 APNIC Region origin ASes announcing only one prefix: 1071 APNIC Region transit ASes present in the Internet Routing Table:612 Average APNIC Region AS path length visible:3.7 Max APNIC Region AS path length visible: 22 Number of APNIC addresses announced to Internet: 486803488 Equivalent to 29 /8s, 4 /16s and 8 /24s Percentage of available APNIC address space announced: 80.6 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:129255 Total ARIN prefixes after maximum aggregation:67559 ARIN Deaggregation factor: 1.91 Prefixes being announced from the ARIN address blocks: 103380 Unique aggregates announced from the ARIN address blocks: 39158 ARIN Region origin ASes present in the Internet Routing Table:13428 ARIN Prefixes per ASN: 7.70 ARIN Region origin ASes announcing only one prefix:5201 ARIN Region transit ASes present in the Internet Routing Table:1323 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 735019296 Equivalent to 43 /8s, 207 /16s and 129 /24s Percentage of available ARIN address space announced: 64.4
New SPAM DOS
At least this is new for me... I host scvrs.org on one of my servers, and, it does not have any outlook or owa services. For some reason, someone decided to try and send this message out to various internet recipients: Dear user of the scvrs.org mailing service! We are informing you that because of the security upgrade of the mailing service your mailbox (x) settings were changed. In order to apply the new set of settings click on the following link: http://scvrs.org/owa/service_directory/settings.php?email=xfrom= scvrs.orgfromname=wa2ibm Best regards, scvrs.org Technical Support. An now I'm having to clean up various blacklistings thinking that my server is a spamvertised web site. Anyone seen this before? Any good techniques for combatting it? Owen
Re: New SPAM DOS
I host scvrs.org on one of my servers, and, it does not have any outlook or owa services. For some reason, someone decided to try and send this message out to various internet recipients: ... Anyone seen this before? Any good techniques for combatting it? If you look more closely at the messages I believe you'll find that they are multipart/alternative, and that the second part gives a slightly modified version of the owa URL. For instance, for my own nethelp.no domain the first part of message says http://nethelp.no/owa/... but the second part specifies URLs like http://nethelp.no.ujjikx.co.im/owa/... http://nethelp.no.ujjiks.net.im/owa/... http://nethelp.no.ikuu8w.com/owa/... http://nethelp.no.ikuu8e.net/owa/... This is a very old trick, seen lots of times in connection with phishing sites, for instance. Steinar Haug, Nethelp consulting, sth...@nethelp.no
RE: New SPAM DOS
Yep. I've been receiving them from several of my domains for a couple weeks. I've been sending the normal complaints to the provider of the IP space in the header but other than that I have no good ideas about combating it. Aaron -Original Message- From: Owen DeLong [mailto:o...@delong.com] Sent: Friday, January 08, 2010 1:22 PM To: Nanog list Subject: New SPAM DOS At least this is new for me... I host scvrs.org on one of my servers, and, it does not have any outlook or owa services. For some reason, someone decided to try and send this message out to various internet recipients: Dear user of the scvrs.org mailing service! We are informing you that because of the security upgrade of the mailing service your mailbox (x) settings were changed. In order to apply the new set of settings click on the following link: http://scvrs.org/owa/service_directory/settings.php?email=xfrom= scvrs.orgfromname=wa2ibm Best regards, scvrs.org Technical Support. An now I'm having to clean up various blacklistings thinking that my server is a spamvertised web site. Anyone seen this before? Any good techniques for combatting it? Owen No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.725 / Virus Database: 270.14.123/2592 - Release Date: 01/08/10 01:35:00
Re: New SPAM DOS
It's a phishing scam: http://isc.sans.org/diary.html?storyid=7918rss On Fri, 8 Jan 2010 12:41:07 -0700 Blake Pfankuch bpfank...@cpgreeley.com wrote: I too have been receiving these to my spamtrap domain... again any ideas to combat this would be helpful. -Original Message- From: Shane Ronan [mailto:sro...@fattoc.com] Sent: Friday, January 08, 2010 12:34 PM To: Owen DeLong Cc: Nanog list Subject: Re: New SPAM DOS I recently started receiving these as well for my domain. Would appreciate anyone's input on what the deal is. On Jan 8, 2010, at 2:22 PM, Owen DeLong wrote: At least this is new for me... I host scvrs.org on one of my servers, and, it does not have any outlook or owa services. For some reason, someone decided to try and send this message out to various internet recipients: Dear user of the scvrs.org mailing service! We are informing you that because of the security upgrade of the mailing service your mailbox (x) settings were changed. In order to apply the new set of settings click on the following link: http://scvrs.org/owa/service_directory/settings.php?email=xfrom= scvrs.orgfromname=wa2ibm Best regards, scvrs.org Technical Support. An now I'm having to clean up various blacklistings thinking that my server is a spamvertised web site. Anyone seen this before? Any good techniques for combatting it? Owen -- John
Re: New SPAM DOS
It's a phish people. I've received several of these for zimmy.co.uk, they lasted about a week, then they stopped. I would suggest waiting this out, if after a week or two they haven't ceased then I would suggest contacting the ISP from where these EMails are originating. As for the blacklisting of your host, contact them and inform this is a phishing scam; this is better delegated to blacklists such as Netcraft rather than SORBS or the like. c On Fri, 2010-01-08 at 11:22 -0800, Owen DeLong wrote: At least this is new for me... I host scvrs.org on one of my servers, and, it does not have any outlook or owa services. For some reason, someone decided to try and send this message out to various internet recipients: Dear user of the scvrs.org mailing service! We are informing you that because of the security upgrade of the mailing service your mailbox (x) settings were changed. In order to apply the new set of settings click on the following link: http://scvrs.org/owa/service_directory/settings.php?email=xfrom= scvrs.orgfromname=wa2ibm Best regards, scvrs.org Technical Support. An now I'm having to clean up various blacklistings thinking that my server is a spamvertised web site. Anyone seen this before? Any good techniques for combatting it? Owen
Re: New SPAM DOS
Unfortunately, I only have the spamcop report sent to me, I don't have the original message. What spamcop sends does not include Content-Type headers or the additional parts of the message, only the plain text portion. Unfortunately, it's turnning things like SPAMCOP into a DOS attack against the sites they are hoping to protect when they start treating the initial advertised URL as being the spam advertised site. Owen On Jan 8, 2010, at 11:39 AM, sth...@nethelp.no wrote: I host scvrs.org on one of my servers, and, it does not have any outlook or owa services. For some reason, someone decided to try and send this message out to various internet recipients: ... Anyone seen this before? Any good techniques for combatting it? If you look more closely at the messages I believe you'll find that they are multipart/alternative, and that the second part gives a slightly modified version of the owa URL. For instance, for my own nethelp.no domain the first part of message says http://nethelp.no/owa/... but the second part specifies URLs like http://nethelp.no.ujjikx.co.im/owa/... http://nethelp.no.ujjiks.net.im/owa/... http://nethelp.no.ikuu8w.com/owa/... http://nethelp.no.ikuu8e.net/owa/... This is a very old trick, seen lots of times in connection with phishing sites, for instance. Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: New SPAM DOS
On Fri, Jan 8, 2010 at 3:52 PM, Owen DeLong o...@delong.com wrote: Unfortunately, I only have the spamcop report sent to me, I don't have the original message. What spamcop sends does not include Content-Type headers or the additional parts of the message, only the plain text portion. Ah, that explains why you didn't know that the underlying URL is not actually to your web site. Here's what the HTML part looks like: tings were changed. In order to apply the new set of settings click on the = following link:brbra href=3Dhttp://nosoliciting.dirtside.com.okqwab.c= om.pl/owa/service_directory/settings.php?email=3dmk...@nosoliciting.dirtsid= e.comfrom=3Dnosoliciting.dirtside.comfromname=3Dmkttsfont size=3D2h= ttp://nosoliciting.dirtside.com/owa/service_directory/settings.php?email=3D= mk...@nosoliciting.dirtside.comfrom=3Dnosoliciting.dirtside.comfromname=3D= mktts/font/abrbrBest regards, nosoliciting.dirtside.com Technical S= upport.brbrMessage ID#MK8S99OOMIEPVRAZDVIG4/font/p And yes, we're all getting a crapload of these but most die in the spam filter so we never see them. The message I quoted from achieved a spam-assassin score of 26. Regards, Bill -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: I don't need no stinking firewall!
bill from home wrote: All, This thread certainly has been educational, and has changed my perception of what an appropriate outward facing architecture should be. But seldom do I have the luxury of designing this from scratch, and also the networks I administer are small business's. My question is at what size connection does a state table become vulnerable, are we talking 1mb dsl's with a soho firewall? some numbers, 100Mb/s will carry 220Kpps worth of 64byte packets, if this is a fairly simple syn attack and your firewall can support 100k new connections a second (that's a fairly fast firewall), you need less than 50Mb/s to nuke it... the maximum size of the state table on a linux derived system with 4GB of ram is north of a million connections so assuming the session rate of the dos is trackable your firewall needs to start aging connections out in an accelerated fashion after about 4 seconds otherwise you're similarly hosed... given the same firewall can probably forward 2-3mpps when it comes to small packet you run out of state long before your run out of forwarding horsepower. Some kind of firewall device that you might put in front of a business cable connection, or fractional ethernet is like to support a much lower connection rate embedded Pentium equivalent or low to mid-range mips might support a rate of 2-10k connections per second at which point the thresh-hold for dosing it based on session rate is quite a bit lower (quite a bit lower than that of a webserver or dekstop pc for example). i.e. if 10kpps of dos will take it out that's like 5Mb/s on a device that might other wise be able to forward 300-500Mb/s interface to interface using large packet. Or as I suspect we are talking about a larger scale? I know there are variables, I am just looking for a rule of thumb. I would not want to recommend a change if it is not warranted. But when fatter and fatter pipes become available at what point would a change be warranted. Thanks Bill Kruchas Dobbins, Roland wrote: On Jan 8, 2010, at 3:21 PM, Arie Vayner wrote: Further on, if you want to really protect against a real DDoS you would most likely would have to look at a really distributed solution, where the different geographical load balancing solutions come into play. GSLB or whatever we want to call it is extremely useful from a general availability standpoint; however, the attackers can always scale up and really distribute their already-DDoS even further (they learned about routeservers and DNS tinkering years ago). Architecture, visibility, and control are key, as are vendor/customer/peer/upstream/opsec community relationships. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
BGP Update Report
BGP Update Report Interval: 31-Dec-09 -to- 07-Jan-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS580061685 5.7% 310.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 2 - AS638921122 1.9% 5.1 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 3 - AS179020582 1.9% 170.1 -- Sprint US 4 - AS982916527 1.5% 20.8 -- BSNL-NIB National Internet Backbone 5 - AS17488 11481 1.1% 9.3 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 6 - AS4270 9432 0.9%1886.4 -- Red de Interconexion Universitaria 7 - AS118309149 0.8% 10.0 -- Instituto Costarricense de Electricidad y Telecom. 8 - AS7018 8869 0.8% 5.7 -- ATT-INTERNET4 - ATT WorldNet Services 9 - AS4755 8171 0.8% 6.3 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 10 - AS144207126 0.7% 18.2 -- CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 11 - AS5803 6684 0.6% 64.9 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 12 - AS2386 6603 0.6% 5.2 -- INS-AS - ATT Data Communications Services 13 - AS6478 5752 0.5% 5.2 -- ATT-INTERNET3 - ATT WorldNet Services 14 - AS8151 5714 0.5% 5.7 -- Uninet S.A. de C.V. 15 - AS4249 5518 0.5% 31.4 -- LILLY-AS - Eli Lilly and Company 16 - AS192625311 0.5% 5.1 -- VZGNI-TRANSIT - Verizon Internet Services Inc. 17 - AS106205120 0.5% 5.1 -- TV Cable S.A. 18 - AS179745035 0.5% 9.3 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 19 - AS256204629 0.4% 31.1 -- COTAS LTDA. 20 - AS701 4582 0.4% 6.3 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS487542161 0.2%2161.0 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 2 - AS4270 9432 0.9%1886.4 -- Red de Interconexion Universitaria 3 - AS200661657 0.1%1657.0 -- MORRISTECH - Morris Technologies, Inc. 4 - AS265161066 0.1%1066.0 -- TMDAS - TMD FRICTION,INC 5 - AS27667 756 0.1% 756.0 -- Universidad Autonoma de la Laguna 6 - AS310551445 0.1% 722.5 -- CONSULTIX-AS Consultix GmbH 7 - AS3786 2102 0.2% 700.7 -- LGDACOM LG DACOM Corporation 8 - AS121221246 0.1% 623.0 -- STJHS - St. Joseph Health System 9 - AS34787 615 0.1% 615.0 -- LYAKH-AS PF Volodymyr Lyakh 10 - AS25244 579 0.1% 579.0 -- DECODE-AS Decode Autonomous System 11 - AS30423 536 0.1% 536.0 -- AMEDI-3-ASN1 - Amedisys, Inc. 12 - AS487281416 0.1% 472.0 -- VODAFONEQATAR Vodafone Qatar Q.S.C. 13 - AS6822 2545 0.2% 424.2 -- SUPERONLINE-AS SuperOnline autonomous system 14 - AS104453312 0.3% 414.0 -- HTG - Huntleigh Telcom 15 - AS178191054 0.1% 351.3 -- ASN-EQUINIX-AP Equinix Asia Pacific 16 - AS43818 313 0.0% 313.0 -- MELLAT-AS bankmellat 17 - AS580061685 5.7% 310.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 18 - AS41625 279 0.0% 279.0 -- ETSERVICE-AS Express Teleservice Corp. 19 - AS36988 550 0.1% 275.0 -- MILLICOM-SL 20 - AS323982175 0.2% 271.9 -- REALNET-ASN-1 TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 170.210.56.0/229289 0.8% AS4270 -- Red de Interconexion Universitaria 2 - 203.253.254.0/24 4200 0.4% AS3786 -- LGDACOM LG DACOM Corporation AS4766 -- KIXS-AS-KR Korea Telecom 3 - 204.214.88.0/244002 0.3% AS1790 -- Sprint US 4 - 69.34.220.0/22 3993 0.3% AS1790 -- Sprint US 5 - 69.69.228.0/22 3993 0.3% AS1790 -- Sprint US 6 - 69.34.252.0/23 3993 0.3% AS1790 -- Sprint US 7 - 67.77.98.0/23 3992 0.3% AS1790 -- Sprint US 8 - 202.5.154.0/24 3225 0.3% AS17557 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 9 - 192.12.120.0/242799 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 10 - 91.212.23.0/24 2161 0.2% AS48754 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 11 - 214.13.24.0/21 1915 0.2% AS5800 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 12 - 214.13.108.0/241813 0.2% AS5800 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 13 - 214.13.99.0/24 1811 0.2% AS5800 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 14 - 214.13.109.0/241811 0.2% AS5800 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 15 - 214.13.32.0/24
The Cidr Report
This report has been generated at Fri Jan 8 21:11:27 2010 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
01-01-10312945 193095
02-01-10313049 193048
03-01-10313009 193058
04-01-10312801 193053
05-01-10313004 193161
06-01-10312993 193010
07-01-10313109 193047
08-01-10313220 193205
AS Summary
33272 Number of ASes in routing system
14161 Number of ASes announcing only one prefix
4376 Largest number of prefixes announced by an AS
AS4323 : TWTC - tw telecom holdings, inc.
92652032 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 08Jan10 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 313107 193199 11990838.3% All ASes
AS6389 4164 308 385692.6% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS4323 4376 1949 242755.5% TWTC - tw telecom holdings,
inc.
AS4766 1944 590 135469.7% KIXS-AS-KR Korea Telecom
AS1785 1796 458 133874.5% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS17488 1464 326 113877.7% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS22773 1124 71 105393.7% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS18101 1034 85 94991.8% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS4755 1281 377 90470.6% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS8151 1577 674 90357.3% Uninet S.A. de C.V.
AS10620 1004 151 85385.0% TV Cable S.A.
AS19262 1050 236 81477.5% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS18566 1059 343 71667.6% COVAD - Covad Communications
Co.
AS8452 1017 304 71370.1% TEDATA TEDATA
AS6478 1092 457 63558.2% ATT-INTERNET3 - ATT WorldNet
Services
AS4808 836 232 60472.2% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS24560 826 223 60373.0% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS3356 1202 616 58648.8% LEVEL3 Level 3 Communications
AS4804 633 70 56388.9% MPX-AS Microplex PTY LTD
AS7303 668 105 56384.3% Telecom Argentina S.A.
AS7018 1588 1027 56135.3% ATT-INTERNET4 - ATT WorldNet
Services
AS4134 1019 479 54053.0% CHINANET-BACKBONE
No.31,Jin-rong Street
AS11492 1154 638 51644.7% CABLEONE - CABLE ONE, INC.
AS7545 937 436 50153.5% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS22047 546 53 49390.3% VTR BANDA ANCHA S.A.
AS4780 616 154 46275.0% SEEDNET Digital United Inc.
AS9443 538 78 46085.5% INTERNETPRIMUS-AS-AP Primus
Telecommunications
AS28573 832 375 45754.9% NET Servicos de Comunicao S.A.
AS9299 663 221 44266.7% IPG-AS-AP Philippine Long
Distance Telephone Company
AS5668 784 345 43956.0% AS-5668 - CenturyTel Internet
Holdings, Inc.
AS17676 565 141 42475.0% GIGAINFRA Softbank BB Corp.
Total 37389115222586769.2% Top 30 total
Possible Bogus Routes
41.223.92.0/22 AS36936
Google Contact
I'm having a strange issue with my traffic to google, could somebody from Google can contact me off-list. Thanks! - Chris -- Chris Murray Stargate Connections Inc. cmur...@stargate.ca 604-606-8988
False Positives for Bad Email
Sorry to bother the list, but, could subscribers @atlasbiz.com and/or @dfw-dc1.skywitelecomm.net please contact me off list? Your spam filters are broken and blocking messages for, um, interesting reasons. Owen
ATT Router down in Newark, NJ
In case this affects any of you: Dear ATT IP Services Customer: This e-mail is to notify you we are currently experiencing an impairment with Newark Gigabit Access Router 1. We expect to have additional information as soon as possible, and we deeply apologize for any inconvenience this impairment may cause you. Our trouble ticket number is 119512734. Below are the IP addresses of your affected circuit(s) for which we have you listed as a contact. If you feel that this list is in error please reply with your change requests. x.x.x.x For more information as it becomes available, please visit our website: https://mis-att.bus.att.comhttp://redir.aspx?C=a34e3c8e8d1949b5a5227a8e887664c2URL=https%3a%2f%2fmis-att.bus.att.com If you require further information please feel free to email ATT at: rm-aw...@ems.att.com Thank you for using ATT. Sincerely The ATT Customer Care Team -- LITTLE GIRL: But which cookie will you eat FIRST? COOKIE MONSTER: Me think you have misconception of cookie-eating process.
Re: False Positives for Bad Email
(a) It might be better to try the relevant postmaster addresses and (b) it also might be better to try the mailop list, where the focus is more on mail than on networking. ---Rsk
Re: I don't need no stinking firewall!
Dobbins, Roland wrote: On Jan 8, 2010, at 9:02 PM, bill from home wrote: And maybe there is no way to tell, but I feel I need to ask the question. Situationally-dependent; the only way to really tell, not just theorize, is to test the firewall to destruction during a maintenance window (or one like it, in the lab). see my post in the subject, a reasonably complete performance report for the device is a useful place to start. if you know what the maximum session rate and state table size for the device are, you have a pretty good idea at what rate of state instantiation it will break. rather frequently it's more than two orders of magnitude lower than the peak forwarding rate. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: I don't need no stinking firewall!
On Jan 9, 2010, at 7:52 AM, Joel Jaeggli wrote: see my post in the subject, a reasonably complete performance report for the device is a useful place to start. The problem is that one can't trust the stated vendor performance figures, which is why actual testing is required. I've seen instances in which actual performance is 5% or less of vendor assertions (i.e., vendor constructed a highly artificial scenario in order to be able to make a specific claim which doesn't hold up in real life). Also note that most vendors don't perform negative testing, astonishing though that may seem. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: I don't need no stinking firewall!
Dobbins, Roland wrote: On Jan 9, 2010, at 7:52 AM, Joel Jaeggli wrote: see my post in the subject, a reasonably complete performance report for the device is a useful place to start. The problem is that one can't trust the stated vendor performance figures, which is why actual testing is required. I've seen instances in which actual performance is 5% or less of vendor assertions (i.e., vendor constructed a highly artificial scenario in order to be able to make a specific claim which doesn't hold up in real life). I'll go out on a limb and just quote myself since you didn't fully. if you know what the maximum session rate and state table size for the device are, you have a pretty good idea at what rate of state instantiation it will break. rather frequently it's more than two orders of magnitude lower than the peak forwarding rate. two orders of magnitude lower is 1% of forwarding rate. It could be lower but it's probably not 3 orders of magnitude. rfc 3511 testing won't tell you that much that's useful in the real world. but it will tell you how many concurrent sessions you can establish (which is almost purely a function of the amount of ram for that data strcture) through the DUT and how quickly you can establish them (which may vary with your rule base but will almost certainly never get better). vendors are mostly honest about that becuase you can trivially replicate that test even with fairly low end equipment on all but the biggest stateful devices. Also note that most vendors don't perform negative testing, astonishing though that may seem. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
