RE: Meta outage
On Tue, 05 Mar 2024 12:17 -0700, Michael Rathbun wrote: > What I found intriguing was that I was logged out by Google Docs at the same > moment FB logged me out. Downdetector showed a number of other supposedly > unrelated services with large outage report spikes at roughly the same time. I was logged out of Honeywell's Total Connect Comfort site (remote thermostat control) at the same time FB logged me out. I'm not using OAUTH logins anywhere. I had recently changed SSID and the thermostat wasn't accepting remote commands. I thought maybe the SSID change had broken it and had just deleted the device from the TCC site to try adding it back when I was logged out. It's funny timing because earlier today I was telling an employee how we don't like to have our maintenance overlap with vendor's maintenance/repair window because when something breaks while we are making changes we can't always tell who is at fault.
RE: Strange IPSEC traffic
I can confirm we started seeing this on Nov 9th at 19:10 UTC across all markets from a variety of sources. If you want to filter it with ingress ACLs they need to include subnet base and broadcast addresses in addition to interface address, so a router at 192.168.1.1/30 with a customer potentially running IPSEC at 192.168.1.2 would require all this to silence the log messages: access-list 100 deny esp any host 192.168.1.0 access-list 100 deny esp any host 192.168.1.1 access-list 100 deny esp any host 192.168.1.3 access-list 100 permit ip any any I started with an ACL only on the interface address and then noticed I was still getting logs on base/broadcast addresses. Could be recon for the IKEv2 vulnerability in this: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-ravpn-auth-8LyfCkeC https://blogs.cisco.com/security/akira-ransomware-targeting-vpns-without-multi-factor-authentication Or zero day. Even though the devices they are hitting are not configured for IPSEC we are filtering it anyway (and for good measure " no crypto isakmp enable"). Mike
Re: TACACS+ server recommendations?
> We are using Okta's RADIUS service for 2fa to network gear currently, > but looking to switch to tacacs+ for many reasons. Would prefer to > implement tacacs+ with two-factor if possible. tac_plus-ng from https://www.pro-bono-publico.de/projects/tac_plus-ng.html has LDAP and PAM backends, among others, so I believe you can implement 2FA through them. I haven't implemented this yet but it's on my to-do list (and I'm also warily watching passkey developments and wondering how much effort I should put into something that likely won't be best practice in another year or two). I see Marc Huber is also promoting/supporting tacacs+ extension for SSH public key auth https://github.com/MarcJHuber/event-driven-servers/wiki/TACACS_PLUS---SSH-Public-Key-Authentication
Re: TACACS+ server recommendations?
> https://www.shrubbery.net/tac_plus/ That tac_plus has python 2 dependencies and so has been removed from Debian packages. That's not surprising given the last update was 2015 and Python 2 was EOL in 2020: https://www.python.org/doc/sunset-python-2/ Currently I favor this one which is still being actively developed: https://www.pro-bono-publico.de/projects/tac_plus.html
Remote code execution bug in FreeBSD's ping (CVE-2022-23093)
Ooof. https://www.freebsd.org/security/advisories/FreeBSD-SA-22:15.ping.asc Some hope here: "The ping process runs in a capability mode sandbox on all affected versions of FreeBSD and is thus very constrainted in how it can interact with the rest of the system at the point where the bug can occur." Lots of other things are based on FreeBSD and may be affected, including firewalls like pfsense and OPNsense and possibly Junos. At the least I expect host discovery is ramping up by now.
RE: SATCOM terminals under attack in Europe
Precedent? https://blog.codinghorror.com/revisiting-the-black-sunday-hack/
RE: Authoritative Resources for Public DNS Pinging
> Do you know if this was codified prior to 1.1.1.1 being taken over by > Cloudflare? Yes, I'm sure it was.
RE: Authoritative Resources for Public DNS Pinging
On a related note, I just discovered a NID that has 1.1.1.1 assigned to the outband interface by default, and it is apparently not user modifiable. So, not only can these devices never use 1.1.1.1 for name resolution, but attempts to determine "is the circuit up" by pinging it will always return bad information. To really pour salt on the wound, this device has no physical outbound interface (likely why the UI doesn't allow changing it). Bug report filed. I don't really want to use it for either purpose, but hopefully a fix saves someone else the headache. And it really chaps my when public addresses get used this way.
RE: Authoritative Resources for Public DNS Pinging
> What else is like that and easy to remember and isn’t 1.1.1.1 ? 4.2.2.1, which IIRC predates both 8.8.8.8 and 1.1.1.1. Muscle memory still favors it. I think 4.2.2.2 might be anycast the same but never really looked hard at it.
RE: Authoritative Resources for Public DNS Pinging
Anyone swinging a clue-by-four it going to hit Meraki real hard. https://community.meraki.com/t5/Switching/Switch-Constantly-Pings-8-8-8-8/m-p/31491
RE: Anyone from Level3/CenturyLink/Lumen, possibly Comcast around?
I can confirm this issue exists at several sites in the Denver area with this same IPSEC issue, all routing between Level3/Lumen and Comcast. I was told by one customer that it resolved late yesterday afternoon but I haven't been able to confirm that. Mike -Original Message- From: NANOG On Behalf Of Brie Sent: Thursday, October 14, 2021 10:43 AM To: nanog@nanog.org Subject: Anyone from Level3/CenturyLink/Lumen, possibly Comcast around? Hi all, So, having a... frustrating issue going on. Long wall of text ahead as I explain. 1 x CenturyLink/Lumen fiber in Boise 1 x CenturyLink/Lumen fiber in Cheyenne 1 x Comcast biz fiber in Denver IPsec VPN tunnels between all three sites, w/ OSPF for routing failover (which unfortunately doesn't help in this situation). Two days ago, Cheyenne to Denver (.196) traffic (both tcp and udp) were an issue initially. Failed over to routing Cheyenne VPN through Boise while we opened ticket with CL. Yesterday, Boise to Denver (.196) traffic started having exact same issue. Tests from another CL fiber in Boise (my own circuit, with legacy IP space and BGP) to Denver (.196) did not show same issues. Path appeared clean. Traceroutes from Office Boise to Denver (.196) had a noticeable difference from Personal Boise to Denver (.196): Office Boise -> Denver (.196) -- 3: sea-edge-15.inet.qwest.net 4: lag-4.ear3.Seattle1.Level3.net 5: ae-2-52.ear2.seattle1.level3.net <-- This hop 6: be-203-pe01.seattle.wa.ibone.comcast.net Personal Boise -> Denver (.196) -- 4: sea-edge-15.inet.qwest.net 5: lag-25.ear2.Seattle1.Level3.net 6: be-203-pe01.seattle.wa.ibone.comcast.net On a whim, tracerouted to another Denver router IP address (.199, IP alias on same interface) from Boise Office, and traceroute matched the traceroute from Personal Boise to Denver (.196) traceroute. No packet loss. Swapped VPN tunnels over to using another ip on same router (.199), same interface physical and logical, in Denver, and VPN was working again normally. This morning though, Cheyenne to Denver (.199) is having problems, while Boise to Denver (.199) isn't (for now). Already spent most of last night working with my partner in Denver replacing nearly everything on the Denver side with no change. Tests from the router above the main Denver VPN endpoint (.196) do not show any kind of issues or packet loss to it, so it doesn't appear the problem is inside of our network. I'm not inclined to think this is a Comcast issue, but I can't be sure. This sounds almost like a load balancing hashing issue, with one link in the bond group having issues, somewhere in one of our upstream's networks. We'll be opening a ticket in a bit through normal channels with CenturyLink/Lumen, but we're worried they're just going to close the ticket as not being their issue. Anyone know of an engineer at CenturyLink/Lumen/Level3 or even Comcast that might want to take a stab at this? I can provide a lot more detail. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
Re: ISC BIND 9 breakage?
Nick Hilliard wrote: > forgot to re-sign the zone on dlv.isc.org or forgot to remove > dnssec-lookaside from the config? > > Not kidding here. People need to take responsibility for their > configurations. Anyone running BIND provided with CentOS 6 has a release from ~2012 (bind 9.8.2) and it is understandable why their documentation is out-of-date (like OP). To get more recent bugs and fixes from ISC directly, install from ISC's copr: https://copr.fedorainfracloud.org/coprs/isc/bind-esv/ On CentOS 7 I needed to install dnf and yum-plugin-copr first. I don't see these in the usual places for CentOS 6, so getting copr sources enabled is the first challenge. ISC sources for other distros: https://www.isc.org/blogs/bind-9-packages/ Mike
Re: DDoS attack
> In any regard, <1 Gbps is pretty piss poor for an amplification attack too. We've observed a customer receiving relative low volume attacks in the last week (so low they didn't trigger our alarms). My working theory is that with the Dec 3rd release of Halo Reach for PC, there are gamers attempting to lag, but not knock off, their opponents. This would be one reason to target adjacent unused addresses.
Re: Hulu thinks all my IP addresses are "business class", how to reach them?
Question: is anyone who is currently suffering this issue also doing 1:many NAT? Or running a proxy server that might cause multiple clients to all appear from the same IP address? I believe NAT might be the cause of one of our customer's complaints wrt content provider blocking.
Re: Reduced ISP uptime after BGP annoucement
Dylan Ebner wrote: Does anyone know if it is the policy of Qwest (or ISPs) to have lower uptime metrics for BGP customers or am I just experiancing lots of downtime with an ISP that is known for having lots of problems? We do BGP to Qwest Internet and they've been as reliable as any other provider over the long haul. There have been 1-2 outages impacting our ELA in the last year - one of which was big enough to take down our MOE services across the state. I can't imagine a good reason to give lower metrics to our BGP customers. We assume the customers who want BGP really value their uptime moreso than others because they are investing more money in it. Now if I have an outage and limited staff to do client contact notifications, we'll call the BGP customers last since they are least affected. But that's about it as far as discriminatory treatment goes. Mike
Re: OOB customer communications (Re: Looking for Support Contact at Equifax)
Suresh Ramasubramanian wrote: If your email and phone communications are down due to a connectivity break, and your customers get connectivity from you [assume no backup links, by default .. you'd be surprised at how many smaller customers get by with a single link and no backups at all. If their connectivity is down too - they just cant get to twitter right? I can post status updates to our noc twitter account from my cell phone (so no reliance on local network) and any customers who are using a smartphone device can get updates from their mobile, also wholly OOB from our network. I imagine there's a way to get updates via pure SMS too. I think it's the melding of the mobile with the Internet that is what gives Twitter its real power. I agree however that if the only Twitter access is via regular computer it loses most of its value in this situation. Mike
Re: OOB customer communications (Re: Looking for Support Contact at Equifax)
William McCall wrote: I should have clarified. Third party physical control isn't necessarily the issue, but third party administration and delivery (in the context of twitter) is. Dedicated servers are cheap and you can maintain control of the content. But useless if the customer's data connection is down and their local cell phones are the only remaining method of communication. If 25% of our users would check their twitter feed first and let their boss know They are aware of the problem and this is the ETR, that means the other 75% who are trying to call have less competition getting that same update from a human (or our auto-attendant). We're never going to tweet every down T1 because those are easy to manage the customer contacts for and also not of interest to 99% of our customers. I'm really only talking about the outages that would affect the majority of customers where proactive notification isn't feasible (by the time you've made it 10% through your list, you've already received calls from 95% of the people who want such notifications anyway because they all called at the same time, right when it stopped working...). Mike
OOB customer communications (Re: Looking for Support Contact at Equifax)
We're experimenting with Twitter as a means to communicate anytime there are system-wide outages (in addition to regular maintenance notifications). Adoption is slow but I foresee growth once we really get the word out. Being a data and VoIP provider, certain events can effect both email and telephone communications, so having a truly OOB method of contact is potentially invaluable. It would be awesome if there was a service like twitter that wasn't down as often as it is. Anyone have a list of all xSPs using Twitter? Mike
Re: The real issue
Shane Ronan wrote: Very simple, just do it. Ha! We have some legacy IP space in continous use here at ASN13345 for over 12 years now that was recently revoked for a few weeks (only to be later restored via a transfer once the exact definition of ownership in a member-owned cooperative was hammered out). Guess what stopped working in the interim? Well the whois records were gone and our abuse desk probably had a tiny decrease in complaints as a result. In some quarters that might be seen as a blessing, but we view abuse reports as cries for help from infected hosts that will become larger service outages if not addressed. Also the in-addr services went away, affecting about a half dozen mail servers out of several thousand hosts in the revoked delegation. We did not receive one single call or complaint about connectivity in that duration apart from the in-addr loss, and those customers were offered smart host use or replacement IPs for the duration. The ones who chose the smart host continued to use the revoked IP space without problem after that. The Internet's greatest strength and greatest weakness is the lack of a central authority who can just do it. I for one am happy it is that way. It's part of what makes us an *autonomous* system, sovereign of our own little kingdom. Mike
Re: Malicious code just found on web server
Paul Ferguson wrote: Most likely SQL injection. At any given time, there are hundreds of thousands of legitimate websites out there that are unwittingly harboring malicious code. Most of the MS-SQL injection attacks we see write malicious javascript into the DB itself so all query results include it. However, I'm not sure how easy it is to leverage to get system access - we've seen a number of compromised customer machines and there didn't appear to be any further compromise of them beyond the obvious. In the OP's case it sounds like static HTML files were altered. My bet is that an ftp or ssh account was brute forced. Mike
Re: downloading speed
chandrashakher pawar wrote: We are level one ISP. one of my customer is connected to fast ethernet. His link speed 100,000 kbps. while downloading any thing from net he downloading speed donot go above 200 kbps. While doing multiple download he get aroung 200 kbps in every window. But when he close all the windows no change in downloading speed is observed. As others have mentioned, duplex mismatch is a good cause. If you have a client with java support, give the NDT a try as this is something it claims to detect: http://ndt.anl.gov:7123/ There's a master site list available here so you may wish to find a closer test site: http://e2epi.internet2.edu/ndt/ndt-server-list.html Caveat: I think most of them are Internet2 only. I know the ANL and CERN sites are accessible to us but didn't try them all. Mike
Re: Fiber cut in SF area
Joe Greco wrote: My point was more the inverse, which is that a determined, equipped, and knowledgeable attacker is a very difficult thing to defend against. The Untold Story of the World's Biggest Diamond Heist published recently in Wired was a good read on that subject: http://www.wired.com/politics/law/magazine/17-04/ff_diamonds Which brings me to a new point: if we accept that security by obscurity is not security, then, what (practical thing) IS security? Obscurity as a principle works just fine provided the given token is obscure enough. Ideally there are layers of security by obscurity so compromise of any one token isn't enough by itself: my strong ssh password (1 layer of obscurity) is protected by the ssh server key (2nd layer) that is only accessible via vpn which has it's own encryption key (3rd layer). The loss of my password alone doesn't get anyone anything. The compromise of either the VPN or server ssh key (without already having direct access to those systems) doesn't get them my password either. I think the problem is that the notion of security by obscurity isn't security was originally meant to convey to software vendors don't rely on closed source to hide your bugs and has since been mistakenly applied beyond that narrow context. In most of our applications, some form of obscurity is all we really have. Mike
Re: Outside plant protection, fiber cuts, interwebz down oh noes!
Rod Beck wrote: Hold on. Who says this sabotage? By the time the second plane hit WTC, intent was apparent. I think in this case intent is also apparent based on proximity (and the previously mentioned reward ATT has posted for the capture of vandals). Mike
Re: Nipper and Cisco configuration results
Subba Rao wrote: Can someone explain why Nipper is saying Rlogin is enabled when I do not see it in the configuration file? Is there something else that I need to be looking at? It's been my experience that the routers are all listening on that port by default, and we notice it as a result of people nmap'ing us: Dec 15 17:27:16 MST: %RCMD-4-RSHPORTATTEMPT: Attempted to connect to RSHELL from a.b.c.d Everything I've read indicates that additional specific configuration is required to actually enable this service. Still, it's always been one of my least favorite things about IOS. If I don't need it, it shouldn't be on. And why doesn't show ip sockets list it at all? If I was a tinfoil hat person, I'd assume that is the NSA's back door. Mike
Earthlink help needed
One of our mail servers can't talk to any of the earthlink MX servers and after two weeks of trying I've got a queue full of undeliverable mail to their subs. Previous attempts at getting help via postmas...@earthlink.net are unanswered. INOC-DBA has no directory entry for them. This old NANOG post (http://www.merit.edu/mail.archives/nanog/msg01582.html) has a valid phone number but invalid extension. So I hit 0 and got a tech anyway. That tech instructed me to forward on my concerns to blockedbyearthl...@abuse.earthlink.net which I did, but nothing more than an auto-response has come back a week later now (and yes, I followed the instructions in the auto-responder and re-submitted in the requested format). Everything I've read indicates that if we are being blocked deliberately I should be getting a 550 SMTP error back. We do not even get a SYN/ACK back (nor ICMP unreachable/prohibited, nor RST) so no SMTP errors are generated from their servers. The MX are all pingable and traceable, so its not a routing problem AFAICT. The mailman server here has paranoid rDNS setup, does not appear on any blacklists, and has never been the subject of any spam complaints. It runs a listserv for a professional legal association which charges members a fee before they are allowed to join the list, so the possibility of unwanted third parties being subscribed is very near zero. TIA and sorry for the noise. We tried having an Earthlink subscriber work this from the other angle. All she got was Earthlink has been blocking port 25 for years you should now this by now! Mike Lewinski -- m...@rockynet.com POTS: 303-629-2860 INOC-DBA: 13345*mjl
Re: Earthlink help needed
Within an hour of making this post I received a call from a very helpful engineer at Earthlink. The problem has been identified and a resolution is in the works. Mike Mike Lewinski wrote: One of our mail servers can't talk to any of the earthlink MX servers and after two weeks of trying I've got a queue full of undeliverable mail to their subs. Previous attempts at getting help via postmas...@earthlink.net are unanswered. INOC-DBA has no directory entry for them. This old NANOG post (http://www.merit.edu/mail.archives/nanog/msg01582.html) has a valid phone number but invalid extension. So I hit 0 and got a tech anyway. That tech instructed me to forward on my concerns to blockedbyearthl...@abuse.earthlink.net which I did, but nothing more than an auto-response has come back a week later now (and yes, I followed the instructions in the auto-responder and re-submitted in the requested format). Everything I've read indicates that if we are being blocked deliberately I should be getting a 550 SMTP error back. We do not even get a SYN/ACK back (nor ICMP unreachable/prohibited, nor RST) so no SMTP errors are generated from their servers. The MX are all pingable and traceable, so its not a routing problem AFAICT. The mailman server here has paranoid rDNS setup, does not appear on any blacklists, and has never been the subject of any spam complaints. It runs a listserv for a professional legal association which charges members a fee before they are allowed to join the list, so the possibility of unwanted third parties being subscribed is very near zero. TIA and sorry for the noise. We tried having an Earthlink subscriber work this from the other angle. All she got was Earthlink has been blocking port 25 for years you should now this by now! Mike Lewinski -- m...@rockynet.com POTS: 303-629-2860 INOC-DBA: 13345*mjl
Re: Dynamic IP log retention = 0?
valdis.kletni...@vt.edu wrote: You *do* realize that has a public address does not actually mean that the machine is reachable from random addresses, right? There *are* these nice utilities called iptables and ipf - even Windows and Macs can be configured to say bugger off to unwanted traffic. And you can put a firewall appliance inline without using NAT as well. The other big benefit to using real public IPs is abuse related. There's a scenario we encounter on a semi-regular basis where we forward a report of an apparently infected host to a customer who responds back: How can I tell which one of our hosts is infected? We've got 200 workstations inside our NAT and this abuse report only has our single public address. So I recommend a packet sniffer inside their LAN or accounting on their firewall. But sometimes the source is a salesperson's laptop, and they've gone on a business trip. So no new reports come in and everyone decides it must have been a false alarm. Now imagine that salesperson only stops back in the office once a month, at random undocumented intervals to make backups. How do we ever track him down? The abuse report cycle just doesn't turn around fast enough - often we don't even get reports for a day or two. So I find myself advising customers in this situation to give every user a public IP. Even if they still do 1:1 NAT, the problem is mostly resolved provided they faithfully document MAC addresses and keep DHCP logs for a suitable length of time. Mike
Re: Dynamic IP log retention = 0?
Joe Greco wrote: A quick scan of the reverse mapping for your address space in DNS reveals that you have basically your entire network on public addresses. No wonder you're worried about portscans when the printer down the hall and the receptionists machine are sitting on public addresses. I think you are trying to secure your network from the wrong end here. Your idea of security is strange and unrealistic. Putting all of your network behind NAT is not a guarantee of security. Amen. Our NOCS workstations all use public IP addresses that are routed through a firewall. The firewall applies appropriate policies that would be functionally no different from applying the same policies to NAT'd hosts. In our environment, we'd gain absolutely nothing from a security perspective by enabling NAT. But it does help ensure that poorly designed applications don't require proxies to support them through NAT (SIP, FTP etc). And we'll never have problems with a partner VPN conflicting with our internal IP space. Mike
Re: anyone else seeing very long AS paths?
German Martinez wrote: Workaround: Configure the bgp maxas limit command in such as way that the maximum length of the AS path is a value below 255. When the router receives an update with an excessive AS path value, the prefix is rejected and recorded the event in the log. This workaround has been suggested previously by Hank. Anyone knows about any possible CPU impacts in case that you implement bgp maxas? bgp max-as will NOT protect you from this exploit (but if you are not vulnerable it should prevent you from propogating it). As far as I can tell the ONLY defense for a vulnerable IOS is to not run BGP. Dropping every received route with a filter on 0/0 does not mitigate the attack - as soon as that bogus as-path is received the BGP session resets, even if the route is never actually installed (and as far as I can tell the only real effect of the bgp maxas-limit 75 is to cause all paths with more than 75 ASN to not be installed in the routing table).
Re: anyone else seeing very long AS paths?
Jack Bates wrote: Just to reconfirm. The issue arrives with sending an update, not receiving? So if an ISP does not have a limit and their IOS cannot handle this, they will send an invalid BGP UPDATE to the downstream peers causing them to reset regardless of their max as-path settings? Just trying to reconfirm, so I can inform my customers if there was anything they could do to prevent it, or if it is actually their provider that instigated the peer reset by sending invalid updates. We were dropping ALL prefixes and the eBGP session was still resetting. I used this filter: ip prefix-list drop seq 1 deny 0.0.0.0/0 ge 32 router bgp neighbor x.x.x.x prefix-list drop in I confirmed via show ip bgp sum that there were 0 prefixes received. Of course show ip bgp nei x.x.x.x received-routes still showed the routes coming in, they just weren't being installed into the tables (or redistributed to any iBGP neighbors). So, to reiterate: 1) bgp maxas-limit 75 had no effect mitigating this problem on the IOS we were using. That is: it was previously verified to be working just fine to drop paths longer than 75, but once we started receiving paths 255 then BGP started resetting. 2) prefix-list drop in ensured that ALL eBGP learned routes were dropped before being installed or re-advertised. eBGP still reset itself every three minutes or so, which was about the length of time it took for the session to restore itself and get to the offending route. I believe that upgraded IOS is the ONLY possibly fix in some cases.
Re: Comcast DNS
There are issues between Google and Comcast in the Denver area for at least the last 12 hours. Pages are sporadically stalling before load (indefinitely as far as I can tell). I found a gmail message I'd sent more than 30 minutes prior still processing. This is affecting all google services that I've tried so far. However, I don't see any evidence this problem is DNS-related, and have not otherwise been experiencing name resolution problems or had any other recent Comcast connectivity issues. So, if there's a clue-wielder from either company around, I'm happy to provide traces and dumps if you want to ping me offlist.
Re: Telstra NOC
Chaim Rieger wrote: Steve Church wrote: Who's the hot chick in the bottom right corner? S thats my sis, want her number ? While today may be international CAPS LOCK DAY (http://capslockday.com), I believe off-topic posting day was last Thursday.
Re: What's with all the long aspaths?
Jon Lewis wrote: Yeah...prepending isn't a big deal...but when someone prepends their own AS 70+ times, I wonder WTF they're thinking. I'm sure they get the attention of NOCs around the world as messages like this show up on consoles Oct 22 04:34:05 MDT: %BGP-6-BIGCHUNK: Big chunk pool request (306) for aspath. Replenishing with malloc This time I couldn't be bothered to dig too deeply into who was the cause.
Re: Procedure to Change Nameservers
Crist Clark wrote: 9) Turn off DNS services at old-dns1 and old-dns2 (i.e. take out the firewall rules that allow queries to those addresses). 10) ... 10 ) Use one of the various sanity checking sites to validate some subset of your hosted domain configurations. We used to like http://www.dnsstuff.com a lot, but they've gone commercial. It's still a great service and possibly worth the money (I bought a membership but will be comparing it with the other free offerings in the coming months before our renewal is up to see if there's really enough value add). Free sites that perform similar DNS configuration checks that I know of are: http://dnssy.com http://www.intodns.com Mike
Re: Exploit for DNS Cache Poisoning - RELEASED
Joe Greco wrote: So, I have to assume that I'm missing some unusual aspect to this attack. I guess I'm getting older, and that's not too shocking. Anybody see it? AFAIK, the main novelty is the ease with which bogus NS records can be inserted. It may be hard to get a specific A record (www.victimsbank.com) cached, but if you can shim in the NS records of your ns.poisoner.com authority, then getting the real target A record is trivial since you'll be asked directly for it (and can wait for the legit clients to ask for it for you). Mike
Re: Exploit for DNS Cache Poisoning - RELEASED
Patrick W. Gilmore wrote: Anyone have a foolproof way to get grandma to always put https://; in front of www? Some tests from my home Comcast connection tonight showed less than desirable results from their resolvers. The first thing I did was to double check that the bookmarks I use when visiting my banking sites all begin https. I was happy to see I had the sense to create them some time ago, by hand, with the https. Even when I receive a notice of a new statement or pending payment on something in the email, and I KNOW it's valid, I'm still visiting it from the bookmark.
Re: Seeking clue @ Cbeyond / ASN17184 and/or other suggestions
I'm very happy to report that my post here found the necessary clue-holders and resolved both the lame DNS and stale email configuration issue. Also, one important followup wrt the whois for their ASN query: Finally, as an additional note, the whois delegation for their ASN seems to be broken: $ whois -h whois.arin.net 17184 [Querying whois.arin.net] [Redirected to rwhois.cbeyond.net:4321] [Querying rwhois.cbeyond.net] [rwhois.cbeyond.net] %rwhois V-1.5:003eff:00 rwhois.cbeyond.net (by Network Solutions, Inc. V-1.5.9.5) %error 230 No Objects Found $ It appears that the breakage is probably in my whois client (though, the exact problem has yet to be diagnosed). The standard whois client for CentOS 5.1 still returns the 230 error: $ whois -h whois.arin.net AS17184 [Querying whois.arin.net] [Redirected to rwhois.cbeyond.net:4321] [Querying rwhois.cbeyond.net] [rwhois.cbeyond.net] %rwhois V-1.5:003eff:00 rwhois.cbeyond.net (by Network Solutions, Inc. V-1.5.9.5) %error 230 No Objects Found I had one private reply pointing out that my original syntax was wrong in omitting the AS string, though I'd tried it every way I could imagine, and verified that the syntax worked for other ASNs. The whois client on my OS X 10.4 returns the desired results: $ whois -h whois.arin.net AS17184 OrgName:CBEYOND COMMUNICATIONS, LLC OrgID: CBEY Address:320 Interstate North Parkway Address:Suite 300 City: Atlanta StateProv: GA PostalCode: 30339 Country:US snip On my ToDo is to dig deeper into the problem and figure out who needs a bug report to fix this. I'm guessing it lies with CentOS/RHEL, and has to do with a failure to use the custom whois port assignment @ Cbeyond. Thanks for all the private replies, especially the one that lead to this resolution! Mike
Re: DNS problems to RoadRunner - tcp vs udp
Sean Donelan wrote: 1. Separate your authoritative and recursive name servers 2. Recursive name servers should only get replies to their own DNS queries from the Internet, they can use both UDP and TCP We've just completed a project to separate our authoritative and recursive servers and I have a couple notes... 1) For the recursive-only, we're using a combination of BIND's query-source address a.b.c.d and listen-on e.f.g.h in the hopes of providing some additional measure of protection against cache poisoning. The listen-on IPs are ACL'd at the borders so non-clients cannot get ANY packets to them. The query-source address itself doesn't appear in the listen-on list either and won't respond to queries. I know this isn't foolproof, but it probably raises the bar slightly against off-net poisoning attempts. 2) The biggest drawback to separation after years of service is that customers have come to expect their DNS changes are propagated instantly when they are on-net. This turns out to be more of an annoyance to us than our customers, since our zone is probably the most frequently updated. 3) I've gone so far as to remove the root hint zone from our auth-only boxes, again out of paranoia (recursion no does the trick, this is just an extra bit of insurance against someone flipping that bit due to a lack of understanding of the architecture). There is one third party we have to use an 'also-notify' by IP address in this case for their zone. Mike
Re: .255 addresses still not usable after all these years?
David Hubbard wrote: I remember back in the day of old hardware and operating systems we'd intentionally avoid using .255 IP addresses for anything even when the netmask on our side would have made it fine, so I just thought I'd try it out for kicks today. From two of four ISP's it worked fine, from Verizon FIOS and Road Runner commercial, it didn't. So I guess that old problem still lingers? The TCP/IP stack in Windows XP is broken in this regard, possibly in Vista as well, though I've yet to have the displeasure of finding out. I have a router with a .255 loopback IP on it. My Windows XP hosts cannot SSH to it. The specific error that Putty throws is Network error: Cannot assign requested address. At least if I ever need to completely protect a device from access by Windows users, I have a good option :) Mike
Re: .255 addresses still not usable after all these years?
Mike Lewinski wrote: The TCP/IP stack in Windows XP is broken in this regard, possibly in Vista as well, though I've yet to have the displeasure of finding out. A co-worker confirms that his Vista SP1 can access our .255 router via SSH.
Re: Problems sending mail to yahoo?
Barry Shein wrote: Is it just us or are there general problems with sending email to yahoo in the past few weeks? Our queues to them are backed up though they drain slowly. I know that Yahoo does greylisting, and we often have a large queue backup as a result of mailing lists with a lot of @yahoo.com addresses. As long as you keep retrying I find that they do eventually get through. Between greylisting and sender callback verification, it seems that overall email delivery is increasing in latency and decreasing in reliability.
