ATT BGP Operations in Miami, FL
Hello, Is there anyone from ATT BGP operations who can contact-me off list please for Miami location? I have an open ticket since early morning and a BGP session not exporting other transit ASNs, which were just working by the morning. Thank you. -- Patrick Tracanelli
Re: Dynamic routing on firewalls.
On 09/02/2015, at 13:25, valdis.kletni...@vt.edu wrote: On Mon, 09 Feb 2015 12:56:37 -0200, Patrick Tracanelli said: On 09/02/2015, at 12:14, valdis.kletni...@vt.edu wrote: On Mon, 09 Feb 2015 11:54:04 -0200, Patrick Tracanelli said: On a bridged firewall you can have the behavior you want, whatever it is. Passing packets with firewall is down, but the box still up. Owen's point is that passing packets if the firewall is down is really poor security-wise. If you run in that configuration, I simply DoS your firewall (probably from one set of IP addresses), and then once it has fallen over and is being bypassed, I send my *real* malicious traffic from some other IP address, totally uninspected and unhindered. Much hilarity, hijinks, and pwnage ensues. Hello Valdis, If this is really the point, I don’t know what system you are talking about The one *you* mentioned - passing packets with firewall is down. Owen was pointing out that is a silly configuration: An explicit decision regarding bypass ports, as I mentioned if someone does not want a redundant approach and doesn’t want availability issues if power is down or system is overloaded. Not an inherit behavior or a must. Not related to being L2 our L3. Just a mentioned possibility. Not a limitation, not a recommendation. In the previous e-mail I mentioned “whatever option you want” upon failure, traffic still flowing, traffic bypassed, traffic dropped, L2+STP redundancy, no redundancy at all. So please don’t refer to one single option and pointing it as a failure of the methodology nature if you consider a decision/project error, and in this case just do it the other way, opting out from bypass and dropping or failing over, upon exhaustion or failure. Back to the point, doesn’t have to be different or limited from what you get in L3 firewalling. On 08/02/2015, at 22:48, Owen DeLong o...@delong.com wrote: Technically true, but bridged firewalls are pretty much passe these days in the real world. As a general rule, when the firewall is shut down, one usually doesn’t want the packets flowing past un-hindered. The fact that this is kind of the default of what happens with bridged firewalls is just one of the many reasons hardly anyone still uses such a thing. -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316...@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br Long live Hanin Elias, Kim Deal!
Re: Dynamic routing on firewalls.
On 08/02/2015, at 22:48, Owen DeLong o...@delong.com wrote: On Feb 8, 2015, at 06:02 , Patrick Tracanelli eks...@freebsdbrasil.com.br wrote: Hello, Some Juniper models actually do a very good job of being both. In reality, a Firewall _IS_ a router, even if it's a bad one. Anything that moves packets from one interface to another is a router. Technically it’s quite not a precise assumption. While routing is much likely an IP core need and OSI Layer 3 related mechanism, a firewall does not have to basic L3 forwarding. It can be a bridged/bright firewall, may fit in front of a router, protecting it, and carrying. Not routing anything. In fact in a fail-safe scenario (from availability perspective) a bridged firewall may be shut down completely and a Bypass por pair taking place will keep traffic flowing, “moving packets from one port to another” without actually ever been a router. Technically true, but bridged firewalls are pretty much passe these days in the real world. As a general rule, when the firewall is shut down, one usually doesn’t want the packets flowing past un-hindered. The fact that this is kind of the default of what happens with bridged firewalls is just one of the many reasons hardly anyone still uses such a thing. Hello Owen, I didn’t get your point. On a bridged firewall you can have the behavior you want, whatever it is. Passing packets with firewall is down, but the box still up. Dropping everything if packet is down. Combining bypass ports + STP you can have the set of availability you wish better for your scenario, from simply bypassing everything like you have no box there, if a software or power failure occurs, or having an active failover bridged together on the bypass port, allowing for full firewalling redundancy if the primary box fails. So you are no leaking options if you are doing it on L2 instead of L3. You have additional ease, redundancy won’t require VRRP or similar stuff since it’s not L3 related. To clarify, I am not saying a bridged firewall is a better option for every sort of scenario. Usually I do L3 firewall with the box being an extra hop on the topology, doing CARP for IP reduncancy, etc. But back to the point that a firewall doesn’t need to L3 forward, I like the idea of having a L2 firewall whenever an extra routing hop is not desired, and still won’t lack features and redundancy options. I have recently added netmap-ipfw in front of BGP routers protecting ‘em from DDoS attacks, adding line-rate firewalling capabilities to a commodity x86/64 box or a T5 card for 10GbE/40GbE, and netmap-ipfw itself acts like mentioned, passing packets back and forth between interfaces without ever routing anything. Sure, there are all kinds of things one can do. Some of them are good ideas, many of them are not. If it works in your environment and you’re OK with the failure modes and other tradeoffs, then more power to you. I’m still missing what you are pointing as failure modes or tradeoffs. IPFW does a pretty decent job on L2 filtering, with a particular exception of “ipfw fwd” which won’t work by default under this setup. I can drop unwanted L2 traffic - in fact I like to only allow IPv4,v6 and ARP by default on LLC, cisco discovery and RARP when needed, everything else dropped on L2. Therefore whenever I decide to add it bright, I still don’t miss anything. Of course, the support for routing protocols is a useful feature in a router and one of the areas where firewalls often fall short. Where you want to put things (in front, behind, etc.) really depends on your topology and the problem you are trying to solve. Personally, I like to keep the firewalls as close to the end hosts as possible. This tends to greatly simplify security policies and make them MUCH easier (and more reliable) to audit. I agree. A firewall belongs better closer to the end hosts being protected. Maybe protection of the router is the only exception when RTBH will not fit the task (or just won’t be enough). DDoS mitigation on site is a questionable and usually losing proposition at best. Other than DDoS mitigation, any good router should be perfectly capable of protecting itself. For protecting a router from DDoS that it cannot properly protect itself, one needs to be able to control or alter the delivery of packets across the upstream link from the upstream side anyway. That is best done by an off-site service such as Akamai’s Prolexic. Sadly true just in theory. On real world, people still run weak and low power boxes as routers, ranging from old Cisco boxes to Routerboards, Edgerouters and x86 boxes without any special card or technologies such as DNA, DPDK, Netmap, and therefore boxes that can’t hardly protect themselves against simple DDoS, while they still can route and do their job on calm water, won’t behave well on storms. We are not always talking about big
Re: Dynamic routing on firewalls.
On 09/02/2015, at 12:14, valdis.kletni...@vt.edu wrote: On Mon, 09 Feb 2015 11:54:04 -0200, Patrick Tracanelli said: On a bridged firewall you can have the behavior you want, whatever it is. Passing packets with firewall is down, but the box still up. Owen's point is that passing packets if the firewall is down is really poor security-wise. If you run in that configuration, I simply DoS your firewall (probably from one set of IP addresses), and then once it has fallen over and is being bypassed, I send my *real* malicious traffic from some other IP address, totally uninspected and unhindered. Much hilarity, hijinks, and pwnage ensues. Hello Valdis, If this is really the point, I don’t know what system you are talking about, that will behave like that. If I run a closed firewall, kernel-path, and it’s unable process, and therefore “allow” the traffic, it will drop. If I run it netmap-ipfw and it’s unable to move the packet from one port to the other, it will drop. So there’s no point where a bridge implicits traffic bypass upon starvation/exaustion, unless this is your option to do so, or a default system behavior, in this case a system that should not act for this purpose. If I remember well (and I remember some effusive expressions like “L2 functions easily enabled at scale on a Junos Trio system”), on a Juniper box bridging is processed on Trio chip - even without IRB set up, as well as firewall (limited matching conditions in a bridged domain). If you can exhaust TRIO from your DoS approach (and the idea is that you can’t exhaust it without exhausting line rate first), you will have no bridging anyway, since L2 learning and forwarding will also be resource starved. But this is just all theoretical, as I mentioned you will probably reach line rate limit first if the box is not configured wrong or wrongly planned. -- Patrick Tracanelli
Re: Dynamic routing on firewalls.
Hello, Some Juniper models actually do a very good job of being both. In reality, a Firewall _IS_ a router, even if it's a bad one. Anything that moves packets from one interface to another is a router. Technically it’s quite not a precise assumption. While routing is much likely an IP core need and OSI Layer 3 related mechanism, a firewall does not have to basic L3 forwarding. It can be a bridged/bright firewall, may fit in front of a router, protecting it, and carrying. Not routing anything. In fact in a fail-safe scenario (from availability perspective) a bridged firewall may be shut down completely and a Bypass por pair taking place will keep traffic flowing, “moving packets from one port to another” without actually ever been a router. I have recently added netmap-ipfw in front of BGP routers protecting ‘em from DDoS attacks, adding line-rate firewalling capabilities to a commodity x86/64 box or a T5 card for 10GbE/40GbE, and netmap-ipfw itself acts like mentioned, passing packets back and forth between interfaces without ever routing anything. Of course, the support for routing protocols is a useful feature in a router and one of the areas where firewalls often fall short. Where you want to put things (in front, behind, etc.) really depends on your topology and the problem you are trying to solve. Personally, I like to keep the firewalls as close to the end hosts as possible. This tends to greatly simplify security policies and make them MUCH easier (and more reliable) to audit. I agree. A firewall belongs better closer to the end hosts being protected. Maybe protection of the router is the only exception when RTBH will not fit the task (or just won’t be enough). Therefore, close to the end host usually means far from the core routers. Unless one is really considering a CPE device doing poorly jobs of “a router and a firewall”... -- Patrick Tracanelli
Re: Checkpoint IPS
Hello, On 06/02/2015, at 11:08, Ray Soucy r...@maine.edu wrote: An IPS doesn't have to be in line. AFAIK this is basically what defines an IPS. It can be something watching a tap and scripted to use something else to block traffic (e.g. hardware filtering options on a router that can handle it). You are naming IPS on what is actually an IDS+Active Response as I mentioned before (my #1 option of choice). Not been online won’t for instance prevent the so called single packet attacks and therefore what should be the advantage of an IPS over an IDS is just thrown away. Which, again, I accept what’s missed for what I still have. But I don’t think it can be named IPS acting passively+actively, since it’s not actually not preventing. An IDS tied into an internal RTBH setup to leverage uRPF filtering in hardware can be pretty effective at detecting and blocking the typical UDP attacks out there before they reach systems that don't handle that as gracefully (e.g. firewalls or host systems). That’s exactly the point I agree and adopt. Maybe a first packet will pass, but it takes longer anyway to be deterministic whether the traffic is common or attack traffic. It’s an IPs there and exausting/starving won’t cause issues to the network, only to it’s own capability. Even if you keep it from being automated and just have it be an IDS that you can have a human respond to is pretty valuable. Not a coincidence that Bejtlich’s NSM101and TCP/IP Weapons School courses are usually sold out on Black Hat. Valuable humans behind the tools will always provide better benefits than what vendors may generically sell/deliver. On Thu, Feb 5, 2015 at 6:40 PM, Patrick Tracanelli eks...@freebsdbrasil.com.br wrote: On 05/02/2015, at 12:31, Terry Baranski terry.baranski.l...@gmail.com wrote: On Thu, Feb 5, 2015 at 8:34 AM, Roland Dobbins rdobb...@arbor.net wrote: I've never heard a plausible anecdote, much less seen meaningful statistics, of these devices actually 'preventing' anything. People tend to hear what they want to hear. Surely your claim can't be that an IPS has never, in the history of Earth, prevented an attack or exploit. So it's unclear to me what you're actually trying to say here. And the fact that well-known evasion techniques still work against these devices today, coupled with the undeniable proliferation of compromised hosts residing within networks supposedly 'protected' by these devices, militates against your proposition. Your tendency of making blanket statements is somewhat baffling given the multitude of intricacies, details, and varying circumstances involved in a complex topic like this. To me, it's indicative of an overly-simplified and/or biased way of looking at things. In any case, go ahead and stick with your router ACLs and (stateful!) proxies. Different strokes. -Terry There's room for a good engineered strategy for protection which won't turn into a point of failure in the overall networking topology. For decades, since first rainbow series books were written and military strategy started to be added to information security, it's always been about defense in depth and layered defense. Today those buzzwords became an incredibly bullshit bingo on sales force strategy on selling magical boxes and people tend to forget the basics. Layers and the depth is not a theory just to be added to drawings and keynote presentations. Considering a simplistic topology for 3-tier (4 if you count T0) depth protection strategy: (Internet)--[Tier-0]--(Core Router)--[Tier1]--(core switch)--[Tier2]--(DMZ)--[Tier3]--(Golden Secret) One security layer (tier, whatever) is there to try to fill the gap from the previous one. How deep you have to dig depends on who you are. If you are the end organization willing to protect the golden secret, how complex is your topology, or if you are the carrier, the telecom the company worried only about BGP, PPS, BPS and availability other than the actual value for what's the real target for the attack (if not availability) In summary, in my experience what will (not) work is: 1) Tier 0 Tier 1 On border, core, (Tier0) or on Tier-1 protection layers (typical firewall/dmz topological position) - Memory and CPU exaustion will shut down your operations (increase latency and decrease availability) easily, if you have a Protecting Inbound Proxy (Web Application Firewall, for the sales jargon), Stateful Firewall or IPS. The thing here is, you are insane or naive if you believe a finite state machine with finite resources can protect you from a virtually infinite (unlimited) source of attacks. No matter how much RAM you have, how much CPU cycles you have, they are finite, and since those amazing stateful w/ deep inspection, scrub, normalization and reassembly features on a firewall will demand at least 4K RAM per session and a couple CPU cycles per test, you have
Re: Checkpoint IPS
Usually, this protection level is for the corporate strategy. The business, not the carrier, the service provider or the network operator. And is a business specific requirement. Meaning it may not exist at all! Now, for me, here is where you add more stateful inspection (still, only what is actually efficient, not that god damn echo reply/request wasting memory to be tracked down - useless!). Here is a good place for a WAF, after firewall and IDS protection took place. WAF is a not a panaceia for anything, it's aimed for specific attacks against applications and protocols, is not resilient to coward attacks (volumetric, L3/L4 exaustion, etc). And a proxy in the end is always a web server, so inherits all it's fragility, and therefore it must be protected as well, before it can actually protect anything else. Host Intrusion Detection central servers (receiving information gathered from HIDS on the actual hosts) also fits Tier3. As well as other host-based controls that may add telemetry information to a central location. Talking about telemetry, it's important everywhere, and while generating flows or snmp info grabbing may impact processing usage on critical core devices, those extra added boxes should also passively help telemetry, with flow generation or minimum capability for snmp servings. Nothing here is new. I am talking about, again, basic stuff discussed for decades on colored cover military books, drafts, discussions and BCPs and really old stuff discussed for people who may be already dead, sometimes (Itojun and other samurais' missed). I'm only mentioning the basic 3 tech domains (firewall, ids, proxy), but the other two basic (pen test, vuln scan) that are more process than technology are important as well. For me, and again this is very personal opinion, I never run an IPS unless the customer really wants to (or a stupid compliance requirement really requires to). An IDS+Active Response is as good as IPS, and the only extra benefit an IPS will add compared to IDS is related to single packet attacks, that ones that will pass quickly enough before the active response blocks it. But single packet attacks are related to poorly written software (or unpatched / not fixed software) since it's not really an attack, it's a trigger to bad code misbehavior and should be addressed on the host. This is a very simple model, and easy to understand. However how many situations we've seen big companies getting completely unavailable or AAA getting broken because people insist to buy (and sell) miracle boxes added to core locations, and those miracle boxes will have amazing deep inspection firewalls or IPS or DLP (whatever it means, Data Loss, Data Leak, it means whatever you want to buy)... There may be a place for those stuff, but it's not on core. Nor on second level protection layers. In the end, ISO27002, PCI-DSS, CIA and AAA triads, what are they worth if you add an IPS to your core? When memory is exausted, processing is starved, you will have packet loss, latency, or you will be completely offline. And what's CIA if you security features are breaking Integrity due to missing packets, or breaking full Availability at all? What you have from CIA? Only confidentiality? Better take that plug off. Same for AAA, if Authorization and Authentication are broken or failed due to exaustion/starvation what you get? Accounting/Auditing? So you will sit and read the logs to find out what went wrong? Discouraging firewall/IDS/proxy protection layers is as bad as over leveraging it. Dosage is what distinguishes the poison from the vaccine. -- Patrick Tracanelli FreeBSD Brasil Tel.: (31) 3516-0800 http://www.freebsdbrasil.com.br Long live Hanin Elias, Kim Deal!
Re: look for BGP routes containing local AS#
” on OpenBGP) might be more “correct” from the BGP perspective, but… it’s just the same original problem. The thing is, workarounds like using allowas-in should always be treated as temporary and is a symptom that something is strange, and a good setup should be aimed to stop having your own ASN on a RIB as-path. It’s also very important to notice that this loop prevention mechanism is also a security mechanism. This security mechanism is sometimes used for a good reason by network engineers. Say, if someone start to DDoS you w/ a good DDoS, with forged/spoofed IP addresses etc. I am not able to block by IP, source-as or anything like since I have no reliable information what's the DDoS real source. But with a little help from upstream providers and a few telemetry (flows) we can map the usual as-path for attacking packets to reach me. Therefore you may decide to manipulate your CIDR advertisements and include the AS number that is common path from the attacking vector to me. I confidently rely that when I add someone else’s AS path in my advertisement, this “someone else” will drop the route as a loop prevention when the announcement reaches their router. So, say, if you are attacked from an unknown spoofed source but you can check it is a certain East Europe or Asia or South America or Russian carrier as a common as-path, you can have the effect of blackholing your advertisement on those ASN hops without dealing with BGP communities or other mechanisms that have to be previously agreed and set among peers. So, on the other hand if you, somehow, disable this mechanism, like I just did with allowas-in, you have a potential security problem where someone announcing your CIDR with your ASN or just your ASN somewhere, and this advertisement happens to reach you, You can be victim of attack of different types, ranging from hijacking to other forms of denial of service. So it makes much more urgent the sense that if by any reason you see your own as on prefixes you receive, and you “just need it on FIB”, you must treat it as a temporary configuration and try to get rid of such workaround, getting yourself another ASN or full meshing iBGP among your locations, as the usual first moves to be taken. Regards, -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316...@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br Long live Hanin Elias, Kim Deal!
Re: look for BGP routes containing local AS#
On 28/01/2015, at 07:32, Song Li refresh.ls...@gmail.com wrote:
Hi Joel,
It is right that the BGP route containing the local ASN will be droped.
However, such routes can still be displayed on router. For example, you can
run show route hidden terse aspath-regex .*local ASN.* on Juniper to
check them. We are looking for those routes. If you can run the command on
your Juniper and find such routes, could you please provider them for us?
Sorry, what do you need exactly? A sample? For education purposes are you
looking for something specific?
You need it to be on Juniper router or other BGP software will do?
I have this scenario from Brazil-US, with specifics getting received both ways
but it’s not Juniper.
Thanks!
Regards!
Song
在 2015/1/28 16:23, joel jaeggli 写道:
On 1/27/15 5:45 AM, Song Li wrote:
Hi everyone,
Recently I studied the BGP AS path looping problem, and found that in
most cases, the received BGP routes containing local AS# are suspicious.
However, we checked our BGP routing table (AS23910,CERNET2) on juniper
router(show route hidden terse aspath-regex .*23910.* ), and have not
found such routes in Adj-RIB-In.
Updates with your AS in the path are discarded as part of loop
detection, e.g. they do not become candidate routes.
https://tools.ietf.org/html/rfc4271 page 77
If the AS_PATH attribute of a BGP route contains an AS loop, the BGP
route should be excluded from the Phase 2 decision function. AS loop
detection is done by scanning the full AS path (as specified in the
AS_PATH attribute), and checking that the autonomous system number of
the local system does not appear in the AS path. Operations of a BGP
speaker that is configured to accept routes with its own autonomous
system number in the AS path are outside the scope of this document.
in junos
neighbor { ipAddress | ipv6Address | peerGroupName } allowas-in number
where number is the number of instances of your AS in the path you're
willing to accept will correct that.
We believe that the received BGP routes containing local AS# are related
to BGP security problem.
You'll have to elaborate, since their existence is a basic principle in
the operation of bgp and they are ubiquitous.
Island instances of a distributed ASN communicate with each other by
allowing such routes in so that they can be evaluated one the basis of
prefix, specificity, AS path length and so forth.
Hence, we want to look for some real cases in
the wild. Could anybody give us some examples of such routes?
Thanks!
Best Regards!
--
Song Li
Room 4-204, FIT Building,
Network Security,
Department of Electronic Engineering,
Tsinghua University, Beijing 100084, China
Tel:( +86) 010-62446440
E-mail: refresh.ls...@gmail.com
--
Patrick Tracanelli
FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
316...@sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
Long live Hanin Elias, Kim Deal!
Re: FL-IX in Miami is ready for new members
On 12/01/2015, at 17:24, Dave Temkin d...@temk.in wrote: Hi all, FL-IX has started issuing LOAs for both 36 NE 2nd Street and NOTA in Miami. If you have a network that peers at either location, we'd love to have you as a member. We've committed to keeping the IX platform free for 3 years (you bring the cross connect; we have pre-negotiated deals for inexpensive riser in 36 NE 2nd). For more information, please see: http://www.fl-ix.net Do you have a suggestion for cost-effective cross connect provider from ZIP 33166 to 36 NE 2nd St. or NOTA? -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316...@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br Long live Hanin Elias, Kim Deal!
Best Practices - BGP community to signal transit announces.
Hello Nanogers, I am acting as transit for a number of ASNs, and my upstream peers do filter my announces (as they should as I understand). Therefore I am in the way to set up a community agreement with 'em asking 'em to allow my transit announces for a certain community I wil signal 'em up. Therefore, I have two doubts which I would like to share and hear out your opinions. Is there any best practices or RFC which shall suggest how this community should be set up? Say, while I do standardize this community to be MY-ASN:1 or MY-ASN:65501, is there a difference? Which community numbers should be used for this purpose, if there are any best practice for this? Other than that, I remember Randi Bush's thread on signaling the upstream provider with communities, where a use with caution warn was issued[1]. Therefore, is my scenario a dont in the dos and donts list of practices on signaling the upstreams? If for some reason I should avoid setting up a community for that, whats the other better way to solve it, instead of asking for all upstream providers, one-by-one to allow the transit prefix to be announced via me? I have searched for their own existing communities and, while some up peers do have an adequated community already in place for that, they wont allow me to announce prefixes in their communities, and not everyone will have a comm for that purpose. [1]http://mailman.nanog.org/pipermail/nanog/2009-November/014767.html Thanks.
Re: Tucows vs Postini
Paul Stewart escreveu: Hi folks... Anyone have much experience with outsourcing antispam/antivirus to Tucows? We use Postini today and are overall pleased. The Tucows pricing seems to be MUCH lower so curious on any feedback... Thanks, Paul I personally run Postini, Tucows' and MailFoundry on the clowd (hosted) for some of my customers, so, its all about my very own personal experience. Tucows has a way better ROI rates, however they used to be very, very unstable, with really higher outages than any other of the mentioned players. Nowadays things just seems to be pretty much improved. However, when downtime is not a problem anymore with Tucows, sometimes messages just happen to take real longer to show up in the inbox. Seems like large mail queue or alike (information-less diagnostics, in other words just a feeling). Therefore performance is still lacking from Tucows compared to Postini and MailFoundry. I dont see any of those problems with Postini. Now, MailFoundry seems to be the most feature-rich option. Specially needed for companies with special security policy needs. Performance and availability is just as good as Postini. Ask your financial people to check out the pricing conditions for MailFoundry, if they believe it worths the TCO, I honestly suggest some attention on this SaaS provider. -- Patrick Tracanelli
