Wow... you've... you've really thought this through. -Steve D
On Mon, Mar 9, 2015 at 8:07 AM, That One Guy <thatoneguyst...@gmail.com> wrote: > I suspected it was discovered, and v10 specifically broke the miner and > the code that called these IPs from a list somehow put them in there. > > If I were a developer I would do things like that, which is why God > intervened everytime I tried to learn to code. I would be in prison, I > would be very pretty, the koolaid lipstick would make my lips cherry red, > and my shirt would be tied in a knot while my milkshake brought all the > boys to the yard. Good thing for me I never learned to code > > On Mon, Mar 9, 2015 at 10:01 AM, Simon Westlake <si...@powercode.com> > wrote: > >> I think your tinfoil hat is a little tight.. ;) If we were going to use >> your billing server as a bitcoin miner, why would we only change the IPs >> when a customer updated their equipment in the portal? And why would we >> even make it visible? If I really wanted to hide a bitcoin miner on your >> billing server, I wouldn't do it by sending your customers to the redirect >> page.. >> >> On 03/09/2015 09:57 AM, That One Guy wrote: >> >> me and my tinfoil hat find it suspiscious that v10 resolved the constant >> overloaded billing servers and this pops up, like there is a list somewhere >> and since the first one I saw was affiliated with bitcoins, Paranoid me >> assumed a developer sometime in the historical chain realized there were >> alot of unused cycles out there under their control. >> >> On Mon, Mar 9, 2015 at 9:51 AM, Josh Luthman <j...@imaginenetworksllc.com >> > wrote: >> >>> Look up variable declaration types. I'm willing to bet someone did the >>> math wrong. I've seen it a couple times before but I can't recall where. >>> >>> While the IPs look random, they're not. >>> >>> Josh Luthman >>> Office: 937-552-2340 >>> Direct: 937-552-2343 >>> 1100 Wayne St >>> Suite 1337 >>> Troy, OH 45373 >>> On Mar 9, 2015 10:47 AM, "That One Guy" <thatoneguyst...@gmail.com> >>> wrote: >>> >>>> Where are these IPs coming from. >>>> >>>> and this is a direct serious question, at any point in time, whether >>>> as a product of bertram or the previous developers, were billing servers >>>> used as a distributed bitcoin mining system? >>>> >>>> On Mon, Mar 9, 2015 at 9:37 AM, Simon Westlake <si...@powercode.com> >>>> wrote: >>>> >>>>> It's not database corruption, but it is a known bug (IP changing when >>>>> MAC is edited in customer portal) and it's fixed in 10.03.32. The patch >>>>> will be out this week. >>>>> >>>>> On 03/08/2015 10:34 PM, Jeremy wrote: >>>>> >>>>> Yes, it seemed like a database corruption issue to me as well. I had >>>>> one customer get the redirect and I went in and looked and he was on a >>>>> completely wrong IP (in a subnet that I happened to be working on earlier >>>>> that day and the evening before). He hadn't even logged into the customer >>>>> portal. The logs didn't show any IP change, but clearly his IP was >>>>> changed >>>>> in the database, as he was working fine on the same IP for months and >>>>> months. That issue and the incorrect assignments when a customer enters a >>>>> new MAC seemed related to me. >>>>> >>>>> On Sun, Mar 8, 2015 at 9:26 PM, CBB - Jay Fuller < >>>>> par...@cyberbroadband.net> wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>> *From:* Jay Fuller - Cyber Broadband Inc >>>>>> *To:* Powercode >>>>>> *Cc:* Cyber Broadband Inc. >>>>>> *Sent:* Monday, February 02, 2015 7:34 PM >>>>>> *Subject:* Re: Ticket Updated [Ticket Number:5841] - weird ip >>>>>> changes during customer portal equipment edits >>>>>> >>>>>> >>>>>> Gentlemen: >>>>>> >>>>>> It has happened again. >>>>>> >>>>>> xxxxxxxxxxxxx, customer 1478, requested a public routable IP address >>>>>> which is >>>>>> in a different address class from what he was assigned at >>>>>> installation. >>>>>> Upon changing the address, he was assigned 104.152.40.91, which is an >>>>>> available address in the "Cullman Public" address range. However, >>>>>> when >>>>>> looking at the ARP response (because the customer is bridged to our >>>>>> main >>>>>> router), I saw another network device already had that IP address. >>>>>> >>>>>> So, I searched for that MAC address, which was 78:24:AF:7B:49:38 , >>>>>> using >>>>>> equipment search, which came back to customer >>>>>> 514, xxxxxxxxxxxxxxxxxxxxx, who had logged into the customer portal >>>>>> on January 29 to >>>>>> install a new router. Upon changing his MAC address, powercode >>>>>> assigned him >>>>>> 104.153.191.25, which is not even in any of our network address >>>>>> ranges. >>>>>> >>>>>> It belongs to: >>>>>> >>>>>> Source: whois.arin.net >>>>>> IP Address: 104.153.191.25 >>>>>> Name: IMDC-KC-LOOPBACKS >>>>>> Handle: NET-104-153-191-0-1 >>>>>> Registration Date: 2/2/15 >>>>>> Range: 104.153.191.0-104.153.191.31 >>>>>> Org: Iron Mountain Data Center >>>>>> Org Handle: IMIML >>>>>> Address: One Federal Street >>>>>> City: Boston >>>>>> State/Province: MA >>>>>> Postal Code: 02111 >>>>>> Country: UNITED STATES >>>>>> >>>>>> >>>>>> This is very similar to our new public IP range which is >>>>>> 104.152.40.0/22 >>>>>> >>>>>> Incidently, it appears this customer was assigned 104.152.40.91 >>>>>> before he >>>>>> attempted to edit his equipment and was changed to 104.153.191.25. >>>>>> Also of >>>>>> note, it appears this only affected the GUI/web interface of >>>>>> powercode, and >>>>>> the router/bmu continued to assign him 104.152.40.91. >>>>>> >>>>>> I will now have to reassign xxxxxxxxx a new IP address since the >>>>>> web/gui >>>>>> gave his IP address to someone else. >>>>>> I hope this information helps you to figure out what is happening. >>>>>> >>>>>> I am still concerned we have some kind of database issue. Weird >>>>>> things like >>>>>> this seem to be happening a lot. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: Powercode >>>>>> To: Cyber Broadband >>>>>> Sent: Thursday, January 22, 2015 2:15 PM >>>>>> Subject: Ticket Updated [Ticket Number:5841] >>>>>> >>>>>> >>>>>> ---------------- Please reply above this line ---------------- >>>>>> Good afternoon Jay, >>>>>> >>>>>> We were able to test from this customer's account, and the same issue >>>>>> that >>>>>> was originally reported to us persisted. We logged into the customer >>>>>> portal, >>>>>> changed the MAC address by one digit, and immediately the customer >>>>>> was >>>>>> issued an IP address of 192.170.241.173. After changing the MAC >>>>>> address back >>>>>> to his current valid one, we then had to manually clear out his IP >>>>>> address >>>>>> in Powercode in order for the BMU to hand out a reservation for >>>>>> 192.168.3.36 >>>>>> via DHCP. >>>>>> >>>>>> At this point, we are going to contact our network engineers for >>>>>> assistance >>>>>> in troubleshooting why this customer would receive a 192.170.xx.xx >>>>>> reservation, as this IP does not fit within any ranges defined in >>>>>> Powercode. >>>>>> We will update you as soon as we've had a chance to go over this with >>>>>> them. >>>>>> >>>>>> >>>>>> >>>>>> -------------------------------------------------- >>>>>> >>>>>> Have you visited our knowledge base? The Powercode knowledge base >>>>>> contains >>>>>> data on all aspects of Powercode, including the BMU. You may also >>>>>> find >>>>>> useful information on our community forum. >>>>>> We endeavor to respond to all tickets within two business days. Our >>>>>> business >>>>>> hours are Monday - Friday, 9AM to 5PM Central time. Please contact us >>>>>> via >>>>>> telephone at (920) 351-1010 <%28920%29%20351-1010> or via Skype at >>>>>> powercode_support with any >>>>>> urgent needs. >>>>>> >>>>>> >>>>>> -- >>>>>> John Mahnke >>>>>> >>>>>> Powercode - The smart choice in ISP billing and OSS >>>>>> powercode.com >>>>>> P: 920-351-1010 >>>>>> E: supp...@powercode.com >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>> *From:* Jeremy <jeremysmi...@gmail.com> >>>>>> *To:* af@afmug.com >>>>>> *Sent:* Sunday, March 08, 2015 9:25 PM >>>>>> *Subject:* Re: [AFMUG] Powercode oddity - Commerzbank Ip space >>>>>> >>>>>> I also have a ticket in about this issue. >>>>>> >>>>>> On Sun, Mar 8, 2015 at 2:10 PM, That One Guy < >>>>>> thatoneguyst...@gmail.com> wrote: >>>>>> >>>>>>> This is known to them? (powercode) >>>>>>> >>>>>>> On Sun, Mar 8, 2015 at 3:00 PM, CBB - Jay Fuller < >>>>>>> par...@cyberbroadband.net> wrote: >>>>>>> >>>>>>>> >>>>>>>> yes, they're aware of it. i pointed this out to them weeks ago. :( >>>>>>>> >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>> *From:* That One Guy <thatoneguyst...@gmail.com> >>>>>>>> *To:* af@afmug.com >>>>>>>> *Sent:* Sunday, March 08, 2015 2:06 PM >>>>>>>> *Subject:* [AFMUG] Powercode oddity - Commerzbank Ip space >>>>>>>> >>>>>>>> I am able to replicate a small issue we are having, trying to >>>>>>>> make the decision of whether it looks like a security issue or just a >>>>>>>> bug. >>>>>>>> >>>>>>>> Through powercode, there are two ways to update equipment, >>>>>>>> through our interface, where we select all the details and through the >>>>>>>> customer portal where all the customers can do is update their MAC >>>>>>>> address. >>>>>>>> >>>>>>>> no problems with our end. >>>>>>>> >>>>>>>> However, when a customer updates their MAC address, it is >>>>>>>> assigning IP space that apparently belongs to this Commerzbank IP >>>>>>>> space 208.74.54.100 and 208.74.54.99. >>>>>>>> >>>>>>>> This IP space is absolutely not in our system, and wouldnt route >>>>>>>> naturally on our network >>>>>>>> >>>>>>>> Net Range 208.74.52.0 - 208.74.55.255 CIDR 208.74.52.0/22 >>>>>>>> Name DKIB-USA Handle NET-208-74-52-0-1 Parent NET208 ( >>>>>>>> NET-208-0-0-0-0 >>>>>>>> <http://whois.arin.net/rest/net/NET-208-0-0-0-0.html>) Net Type Direct >>>>>>>> Assignment Origin AS >>>>>>>> Organization Commerzbank AG (COMMER-109 >>>>>>>> <http://whois.arin.net/rest/org/COMMER-109.html>) >>>>>>>> >>>>>>>> My initial thoughts are this is some bug in powercode. >>>>>>>> >>>>>>>> Paranoid me is that our system is somehow compromised and >>>>>>>> rerouting illegitimate traffic somehow. Customer is down, so not >>>>>>>> through >>>>>>>> them. but something like TOR rerouting or some other magician script >>>>>>>> for >>>>>>>> the axis of evil. >>>>>>>> >>>>>>>> Anybody have any ideas on this? I am debating taking our billing >>>>>>>> server offline, but would hate to take such an extreme measure for what >>>>>>>> could amount to nothing more than a fat finger from a programmer. >>>>>>>> >>>>>>>> -- >>>>>>>> If you only see yourself as part of the team but you don't see >>>>>>>> your team as part of yourself you have already failed as part of the >>>>>>>> team. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> If you only see yourself as part of the team but you don't see >>>>>>> your team as part of yourself you have already failed as part of the >>>>>>> team. >>>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Simon Westlake >>>>> Powercode - The smart choice in ISP billing and OSS >>>>> powercode.com >>>>> P: 920-351-1010 >>>>> E: si...@powercode.com >>>>> >>>> >>>> >>>> >>>> -- >>>> If you only see yourself as part of the team but you don't see your >>>> team as part of yourself you have already failed as part of the team. >>>> >>> >> >> >> -- >> If you only see yourself as part of the team but you don't see your >> team as part of yourself you have already failed as part of the team. >> >> >> -- >> Simon Westlake >> Powercode - The smart choice in ISP billing and OSS >> powercode.com >> P: 920-351-1010 >> E: si...@powercode.com >> > > > > -- > If you only see yourself as part of the team but you don't see your team > as part of yourself you have already failed as part of the team. >
