I understand the issue because it was part of my learning experience when
the company I worked for in the 80's was acquired by Rockwell International.
Sales dragged me along on a sales call to try and sell some digital carrier
product to a Bell company. The customer said I will look at your product
when you fix the <fill in the blank> I bought from you. We protested that
was from a totally unrelated division of Rockwell, like maybe the M13 mux
people in Texas, or the Collins Radio people in Iowa, I forget.
Customer pointed to the logo on our product, the logo on the lemon he had
bought, and the logo on our business cards. They all said Rockwell. He
didn't care what division we were from. He had a problem with our company,
and he was holding us responsible.
-----Original Message-----
From: Josh Reynolds
Sent: Thursday, May 05, 2016 1:37 PM
To: [email protected]
Subject: Re: [AFMUG] UBNT CPE being used for Abusive actions?
Wow, let's not be objective or anything.
Cisco makes some shit products. They make some good ones too.
Juniper makes some shit products. They make some good ones too.
Crayola makes some shit products. They make some good ones too.
GE makes some shit products. They make some good ones too.
$vendorOfChoice makes some shit products. They make some good ones too.
(continue)
On Thu, May 5, 2016 at 1:26 PM, Josh Baird <[email protected]> wrote:
Um, well, airFiber IS a Ubiquiti product, so it's not that stupid. They
may
run different operating systems, be designed by different teams and have
different feature sets, but it still says Ubiquiti on it.
On Thu, May 5, 2016 at 11:17 AM, Chuck Macenski <[email protected]>
wrote:
I hate it when people lump airFiber into these things. I know of no
security holes in airFiber that don't require you to already be logged
into
the unit (where you can change the configuration until your heart's
content). AirFiber also supports a very simple to configure management
VLAN
(I don't know how it could be simpler) to keep inband managment traffic
away
from the IP of the unit. If that isn't enough, you can simply disable
inband
management and use the out-of-band management port; no one can then
access
the management traffic from the user traffic flows.
Good morning :)
Chuck
On Wed, May 4, 2016 at 11:39 PM, Mathew Howard <[email protected]>
wrote:
5.6.2, I think, fixed one of them more serious security flaws, and that
was released less than a year ago... and it looks like 5.6.3 and 5.6.4
(which was released very recently) also had security fixes. I believe
most
of those vulnerabilities applied to the AC and airFiber firmware as
well.
Ubiquiti has been good about releasing fixes quickly when they find
vulnerabilities, but that doesn't help if nobody bothers to update
anything.
On Wed, May 4, 2016 at 9:12 PM, Eric Kuhnke <[email protected]>
wrote:
I know about the very old firmware version for M series stuff that is
vulnerable to a known worm.
But let's assume you do have ubnt devices with public IPs (which is a
bad idea). What's the attack surface? http, https, ssh, snmp
Provided you have chosen a reasonably complex admin login and password
there are no current, known remote root exploits for current (or within
the
past 2 years) ubnt firmware on M or AC devices, right?
On Wed, May 4, 2016 at 7:00 PM, Josh Luthman
<[email protected]> wrote:
Public IP on Ubnt. What else do you need to know?
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
On May 4, 2016 9:59 PM, "Eric Kuhnke" <[email protected]> wrote:
The thread got this far and noone has wondered how the CPE was pwned
in the first place?
On Wed, May 4, 2016 at 6:55 PM, Mathew Howard <[email protected]>
wrote:
Yeah, I looked at setting it up that way at one point, but something
didn't look like it was going to work quite the way I wanted it
to... but I
probably spent all of five minutes on it, so it may very well be
possible.
The way ePMP does it is really nice though... and simple.
On Wed, May 4, 2016 at 8:38 PM, Josh Luthman
<[email protected]> wrote:
People do it for sure. I want to say there was an example on the
forums or some where...
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
On May 4, 2016 9:35 PM, "Mathew Howard" <[email protected]>
wrote:
I have our ePMP's setup to get their public IP via PPPoE, and the
radio also gets a completely separate private management IP via
DHCP, which
is the only way you can remotely access the radio, and it doesn't
even have
to be in a separate vlan unless you want it to be... and it's one
checkbox
to configure it.
I'm not sure if that can be duplicated on UBNT or not, since I
haven't really tried yet, but at the very least it's a lot more
complicated
to configure.
On Wed, May 4, 2016 at 7:04 PM, Josh Luthman
<[email protected]> wrote:
It does...you just need to set it up that way.
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
On Wed, May 4, 2016 at 7:54 PM, Mathew Howard
<[email protected]> wrote:
I really wish Ubiquiti radios had a separate management vlan
option (in router mode), like ePMP does...
On Wed, May 4, 2016 at 6:10 PM, Josh Reynolds
<[email protected]> wrote:
I would encourage you to put your CPEs on a management vlan, in
RFC1918 space.
On Wed, May 4, 2016 at 6:00 PM, SmarterBroadband
<[email protected]> wrote:
> Hi Tushar
>
>
>
> We run all radios in NAT mode.
>
>
>
> Adam
>
>
>
> From: Af [mailto:[email protected]] On Behalf Of Tushar
> Patel
> Sent: Wednesday, May 04, 2016 3:34 PM
> To: [email protected]
> Subject: Re: [AFMUG] UBNT CPE being used for Abusive actions?
>
>
>
> Radios could be put on private ip so nobody from outside
> world
> can access
> it. That is what we do.
>
> Tushar
>
>
>
>
> On May 4, 2016, at 5:22 PM, SmarterBroadband
> <[email protected]>
> wrote:
>
> I have received a number of emails for [email protected]
> saying certain of
> our IP address are being used for attacks (see email text
> below).
>
>
>
> All IP addresses are in UBNT radios. We are unable to remote
> access any of
> the these radios now. We see that the radio we are unable to
> access
> rebooted a couple of days ago. A number of other radios show
> they rebooted
> around the same time (in sequence) on the AP. We are unable
> to remote
> access any of those either. Other radios with longer uptime
> on
> the AP’s are
> fine.
>
>
>
> We have a tech on route to one of the customer sites.
>
>
>
> We think the radios are being made into bots. Anyone seen
> this or anything
> like this? Do the hackers need a username and password to
> hack a radio?
> I.E. Would a change of the password stop the changes being
> made to the
> radios? Any other thoughts, suggestions or ideas?
>
>
>
> Thanks
>
>
>
> Adam
>
>
>
> Email Text below:
>
>
>
> “This is a semi-automated e-mail from the LG-Mailproxy
> authentication
> system, all requests have been approved manually by the
> system-administrators or are obviously unwanted (eg. requests
> to our
> spamtraps).
>
> For further questions or if additional information is needed
> please reply to
> this email.
>
>
>
> The IP xxx.xxx.xxx.xxx has been banned for 48 hours due to
> suspicious
> behaviour on our system.
>
> This happened already 1 times.
>
> It might be be part of a botnet, infected by a trojan/virus
> or
> running
> brute-force attacks.
>
>
>
> Our affected destination servers: smtp.light-gap.net,
> imap.light-gap.net
>
>
>
> Currently 7 failed/unauthorized logins attempts via SMTP/IMAP
> with 6
> different usernames and wrong password:
>
> 2016-05-04T23:48:40+02:00 with username
> "downloads.openscience.or.at"
> (spamtrap account)
>
> 2016-05-04T22:47:19+02:00 with username "sp_woq" (spamtrap
> account)
>
> 2016-05-04T14:55:11+02:00 with username "info" (spamtrap
> account)
>
> 2016-05-03T21:24:22+02:00 with username "fips" (spamtrap
> account)
>
> 2016-05-03T20:57:19+02:00 with username
> "downloads.openscience.or.at"
> (spamtrap account)
>
> 2016-05-03T10:13:59+02:00 with username "d10hw49WpH"
> (spamtrap
> account)
>
> 2016-05-03T05:34:43+02:00 with username "12345678" (spamtrap
> account)
> Ongoing failed/unauthorized logins attempts will be logged
> and
> sent to you
> every 24h until the IP will be permanently banned from our
> systems after 72
> hours.
>
>
>
> The Light-Gap.net Abuse Team.”
>
>