Re: dns cache beyond ttl - viasat / exede
I've seen similar issues (years ago) where some ISPs didn't honour DNS TTLs, and would instead cache the results a LOT longer. On Mon, Oct 7, 2019 at 9:08 AM Mike wrote: > Hello, > > > I am moving a number of web sites from one colo to another, > re-numbering them in the process, and I have run into an interesting > issue I'd like to solicit feedback on. > > My dns TTL's are all 300 seconds, and I have noticed that once I > update the A records with the new addresses, most (but not all) web > clients begin using the new address within 5 minutes or so. However, > there is a persistent set of stragglers who continue accessing the > site(s) on their old addresses for far in excess of this - up to a week > in fact. And, what I have noted, all of these clients have something in > common - they all appear to be satellite users of viasat/exede. This is > based on whois lookups of the ip addresses of the clients. Note, I am > NOT expecting 'turn on a time' - just looking for clients to refresh > within a reasonable time. > >I am wondering if perhaps this is due to some kind of (known?) > bug in the embedded dns cache/client in the client satellite modem, or > if there is another plausible explanation I am not seeing. It compounds > my problem slightly since I have to continue running the web sites at > both the old and new addresses while these things time out I guess and > it's just inconvenient. > > > Thanks. > > > MIke- > >
Re: Internet access for security consultants - pen tests, attack traffic, bulk e-mail, etc.
I work for a MSSP (Managed Security Services Provider) that provides some of these services including vulnerability scanning and such. If it's a legitimate provider doing work for customers, you should never get a complaint about their activities. Before we do any kind of scan, we have a contract in place with the customer and include the IP(s) we'll be scanning from and the range of IPs we'll be scanning (assuming this is an external scan). If they're not getting permission from customers first, they are almost certainly breaking laws by scanning systems they don't have permission to, and I wouldn't host them. Assuming you have a legal department, just make sure that you put something that says this type of activity will only be permitted when the target has agreed to the scan in advance. If you get some complaints, investigate, and if they're breaking the contract, turf them. On Mon, 11 Sep 2017 at 16:01 james machado wrote: > On Mon, Sep 11, 2017 at 3:40 PM, Sean Pedersen > wrote: > > > We were recently approached by a company that does security consulting. > > Some > > of the functions they perform include discovery scans, penetration > testing, > > bulk e-mail generation (phishing, malware, etc.), hosting fake botnets - > > basically, they'd be generating a lot of bad network traffic. Targeted at > > specific clients/customers, but still bad. As an ISP, this is new > territory > > for us and there are some concerns about potential impact, abuse reports, > > reputation, authorization to perform such tests, etc. > > > > > > > > Does anyone have experience in this area that would be willing to offer > > advice? > > > > > > From a customer point of view: > > We have written agreements with our vendors on who they can and can not > send this traffic from, where exactly it is coming from and what type of > traffic it will be. One reason our vendor does this is to not get on black > hole/spam lists or to cause their ISP issues, as well as having proof that > they are allowed to send specific traffic to specific addresses for a > specific time period. The test managers then know what to expect and to > head off abuse notifications after detection of the specific traffic. We, > also, use this traffic to test other vendors we might have and only after > detection we will have white lists or black lists put in place as > warranted. > > I would expect the company in question to be able to provide documentation > that could track any specific traffic back to an engagement that has the > approval of their customer. If they have been around for a bit they should > have a track record and may have current IP space that could be vetted to > see what condition it is in. Are they leaving it or adding too it. If > they are leaving their current space then find out why. > > James >
Re: US/Canada International border concerns for routing
Canadian here who's evaluated service providers and dealt with legal requirements for our customers... Generally we weren't worried about data travelling through the US based on normal internet routes, as long as it was encrypted. The thing we usually specified in RFPs was that the data could never be stored in the US. On Tue, 8 Aug 2017 at 17:52 Dave Cohen wrote > It seems to me the original question was asking about it more from a legal > perspective, in other words does Canadian traffic have to stay in Canada. > IANAL (or a Canadian), but the answer is "mostly, no, especially as related > to publicly routed traffic" as should be evidenced based on what's already > been discussed here. In other words, there is restricted traffic but unless > you're making a play for MAN/WAN type service on owned infrastructure, > those requirements are unlikely to arise. > > To support the macro point, there is some big-boy level peering in Toronto > but not really much else outside that, but there are plenty of routes that > don't cross the border if you don't have to jump networks to your > destination, for example going to an AWS on ramp in Canada using a native > partner network, especially in the Toronto-Ottawa-Montreal. > > Dave Cohen > craetd...@gmail.com > > > On Aug 8, 2017, at 8:41 PM, Bill Woodcock wrote: > > > > > > --Apple-Mail=_8DA28412-F6D0-43D8-A90F-5E151E54468E > > Content-Transfer-Encoding: quoted-printable > > Content-Type: text/plain; > >charset=us-ascii > > > > > >> On Aug 8, 2017, at 5:33 PM, Clayton Zekelman wrote: > >> =20 > >> =20 > >> =20 > >> With the peering policies of the major Canadian ISPs, you're virtually = > > guaranteed to hairpin through the US on most paths. > >> =20 > >> Robellus (Rogers, Bell & Telus) will peer with you at any of their = > > major Canadian peering points, such as NYC, Chicago or LA. > > > > To be fair, Rogers does peer in Toronto. Along with New York, Chicago, = > > Seattle, and Ashburn. > > > >-Bill > > > > > > > > > > > > --Apple-Mail=_8DA28412-F6D0-43D8-A90F-5E151E54468E > > Content-Transfer-Encoding: 7bit > > Content-Disposition: attachment; > >filename=signature.asc > > Content-Type: application/pgp-signature; > >name=signature.asc > > Content-Description: Message signed with OpenPGP > > > > -BEGIN PGP SIGNATURE- > > > > iQIcBAEBCAAGBQJZilooAAoJEG+kcEsoi3+HgNsQAIPkgL/lVL/j1sdPyiyQsepE > > TCyHm4bsAq6m085kXoRj/IWn+KsVwmAq8ZGKnKEAiozmrSeyxAa2vmw5Kfs57l1/ > > crBima+EOOlPT4VcD7tv9e8yEiVdjDuMp5tnLI238qCfIlHeHRtuU7CClzWPv6uD > > 3jCNIBEcScrLWz37Ofm/D2AkYRAhhK5H8I417Y/39TH4MIoIKFsGbvWwpl30Fv8r > > 5phO0MrTP6mB8niHne6HTxyMED5TGQpVEL2Qgh6qgaI9vzAs5/47KwwY57tZpxaL > > v9GjkPJ4Ql7QVWbsSkXnFmHxXzqaHXAfg8SR+gsCN42Jyn99AIyAAwdALhqc4RuZ > > ydi+lOlEutAMndA01CnrI81Eu/RpWrN+q/vi37W2rb6EPTPcCz2196JDlpC6VVW6 > > tJOMNuP6Pa/ee52Cxu6RWwA4QZ6QVIT9fbDcRFXTGNuohwP8XVpujcsPLChzsFXA > > Y2nt+TliL697lTZNbTZEzQ0f9w2rpCDpcLjTMCR8MNWZ4MjQHL3eDgO5ZIWHPTQf > > ggR1Dz2EhPSXXZdvN7KPh1q9rhRb2VUPSn3EeEDo2TjgUVeUlunsDg/ILpf8lxUY > > RTsXe5Nky7YqXKDG4HSlLF3R/RtfaVqKJfjljYg351cs40rzivzjD2TJ8r35RQeW > > btKUtEvrcU28g15nOhLG > > =MTUG > > -END PGP SIGNATURE- > > > > --Apple-Mail=_8DA28412-F6D0-43D8-A90F-5E151E54468E-- > > >
Re: Please run windows update now
Just a note folks that while this particular ransomware is using the MS17-010 exploit to help spread, it does not rely on it. This is still a regular piece of ransomware that if someone opens the malicious file, will encrypt files. SANS has some IoCs and more information: https://isc.sans.edu/forums/diary/Massive+wave+of+ransomware+ongoing/22412/ On Fri, 12 May 2017 at 11:45 Josh Luthman wrote: > MS17-010 > https://technet.microsoft.com/en-us/library/security/ms17-010.aspx > > > Josh Luthman > Office: 937-552-2340 <(937)%20552-2340> > Direct: 937-552-2343 <(937)%20552-2343> > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Fri, May 12, 2017 at 2:35 PM, JoeSox wrote: > > > Thanks for the headsup but I would expect to see some references to the > > patches that need to be installed to block the vulnerability (Sorry for > > sounding like a jerk). > > We all know to update systems ASAP. > > > > -- > > Later, Joe > > > > On Fri, May 12, 2017 at 10:35 AM, Ca By wrote: > > > > > This looks like a major worm that is going global > > > > > > Please run windows update as soon as possible and spread the word > > > > > > It may be worth also closing down ports 445 / 139 / 3389 > > > > > > http://www.npr.org/sections/thetwo-way/2017/05/12/ > > > 528119808/large-cyber-attack-hits-englands-nhs-hospital- > > > system-ransoms-demanded > > > > > >
