Press "Enter" to skip to content

Boise Tech Blog

ImageNet Consulting Decides To Pocket Employee’s Stimulus Checks

The Lost Ogle has a great post about the actions of one Oklahoma City company, ImageNet Consulting, that has decided that their employees don’t need paychecks due to the govt surplus checks.

It was also covered by KXAN – but they wouldn’t name and shame like The Lost Ogle did. There is also a Reddit post here with comments and other links.

Oh, they even want half of the $500 per kid stipend too!

If your company is trying to do something similar to you – contact a lawyer that specializes in employment law ASAP.

Update: The company appears to be trying to purge articles, blog posts, etc about their actions from the web and various search engines.

‘Official’ Documents Fraud: “Records Division” dmpoptout.com, Direct Mail Processing LLC

Got an interesting bit of mail today, pretending to be ‘time sensitive’ ‘second notice’ ‘important documents’:

The Envelope

The from is ‘Records Division’, P.O. Box 2910, Kennesaw, GA 30156-9843.

Inside, there was a document labeled ‘T-2’ and titled ‘2020 Benefit Information For Idaho Citizens Only’.

The Insert Meant To Look Like A Tax Document

Looks an awful lot like an IRS or state tax document, right?

Of course, after all of the official looking (but fake) text, they include ‘Not affiliated with or endorsed by any government agency.’ in small letters.

There’s also a web address, dmpoptout.com.

Where To Send It To

This fake ‘tax’ document is supposed to be mailed back to Direct Mail Processing, LLC P.O. Box 100080, Kennesaw, GA 30156-9912.

A quick google of dmpoptout.com brings up some interesting background on this company. ScamPulse in particular has some interesting reports – most of them about misleading mailings targeting elderly victims.

dmpoptout.com makes dubious claims of not being involved with the scam mailings they are handling:

Their Website Claims

Protect yourself and your friends and family by making sure they can recognize these scams. As always, if you believe you have been the victim of a scam, contact your state’s consumer protection agency.

Configuring DNSDist – A Basic Config

DNSDist is a great load balancing DNS forwarder/resolver designed by the same people behind PowerDNS.

It works on Linux and other UNIX OSs, and is fairly easy to set up once you understand how its configuration file works.

An example config with some comments…

controlSocket('127.0.0.1:5199')
setConsoleACL('127.0.0.1/32')
setKey("PUT-KEY-HERE")
addLocal('127.0.0.1')
addLocal('10.0.0.1')
addLocal('::1')
webserver('10.0.0.1:8083', 'dnsdist', 'dnsdist')

This is the initial section defining what IPs DNSDist uses to listen for its control and general purpose sockets:

  • controlSocket() – sets local IP and port that the control listens on
  • setControlACL() – sets what can connect to the control socket
  • setKey() – sets your unique key to prevent unauthorized access
  • addLocal() – sets the local IP and port that the resolver listens on
  • webserver() – sets the local IP and port that the stats webserver listens on, with the username and password it expects
addDOHLocal("172.16.5.1:5053",
                "/etc/letsencrypt/live/domain.com/fullchain.pem",
                "/etc/letsencrypt/live/domain.com/privkey.pem",
                "/dns-query",
                { doTCP=true, reusePort=true }
                )
doh_ips=newNMG()
doh_ips:addMask('0.0.0.0/0')
doh_ips:addMask('::/0')
addAction(AndRule({NetmaskGroupRule(doh_ips, true), DSTPortRule(5053)}), PoolAction('recursive'))

This section we set up DNS over HTTPS for use with Firefox, Chrome, etc that can take advantage of a secure channel to query DNS separate from their provider’s servers.

In this case, we’re allowing anyone to query over DOH, but you can change that by removing the addMask() covering ‘everything’.

  • addDOHLocal() – this sets the local IP and port that the DOH HTTPS server listens on. The paths are to the local letsencrypt generated certificates. The “/dns-query” path is the web server path to use as the base for the queries.
  • doh_ips=newNMG() – sets up the Network Mask Group variable
  • doh_ips:addMask() – configures the source IP ranges to allow
  • addAction() – this one in particular allows anyone from the doh_ips variable who queries DOH on port 5053 to recursive query DNS.
recursive_ips=newNMG()
recursive_ips:addMask('127.0.0.0/8')
recursive_ips:addMask('::1/128')
recursive_ips:addMask('fe80::/10')
recursive_ips:addMask('10.0.0.0/24')
addAction(NetmaskGroupRule(recursive_ips), PoolAction('recursive'))

This section we set up the standard port 53 UDP/TCP resolver to accept queries. It works the same way as the previous block does, with the exception of the addAction().

  • addAction() – this allows anyone from recursive_ips variable to query your resolver on port 53 UDP or TCP.
newServer({address="8.8.8.8:53", pool="recursive"})
newServer({address="1.1.1.1:53", pool="recursive"})

recursivepc = newPacketCache(10000, {maxTTL=86400, minTTL=0, temporaryFailureTTL=60, staleTTL=60, dontAge=false})
getPool("recursive"):setCache(recursivepc)

setACL({'::/0','0.0.0.0/0'})

This section sets up the recursive pool of servers to use for querying.

  • newServer() – sets the parent recursive DNS servers to balance between. In the above examples, we use two public ones – Google and Cloudflare. Can be your provider’s recursive or other public ones.
  • recursivepc=newPacketCache() – sets up the details on the packet cache to improve performance and expire old entries.
  • getPool():setCache() – links the recursive pool to the recursivepc packet cache defined before
  • setACL() – needed to allow any incoming queries to hit the Netmask Group ACLs previously defined.

Installing The Unifi Controller On Debian Buster

IHere’s what you need to do to run the Unifi Controller on Debian Buster:

Add the following to /etc/apt/sources.list:

deb http://repo.mongodb.org/apt/debian jessie/mongodb-org/3.4 main

Do:

wget -qO - https://www.mongodb.org/static/pgp/server-3.4.asc | apt-key add -

(thx u/theinvisibleman_ for the key update info on his post here)

Grab:

http://security.debian.org/debian-security/pool/updates/main/o/openssl/libssl1.0.0_1.0.1t-1+deb8u12_amd64.deb
http://security.debian.org/debian-security/pool/updates/main/o/openjdk-8/openjdk-8-jre-headless_8u232-b09-1~deb9u1_amd64.deb

Do:

 dpkg -i <package deb file>

To install both of those packages. Then:

 apt-get update

And install the mongodb packages:

 apt-get install mongodb-org-server mongodb-org-tools mongodb-org-shell

This should give you all you need to install the controller deb.

If I missed any depends, let me know as I threw this together after the fact and may have forgotten something.

IODD 2531 – The Better Way To Do USB Boot Media

I’ve had one of the IODD USB storage devices for a while – specifically the IODD 2531.

It’s a great little device – an external USB enclosure with a display that allows you to select ISO images to ‘insert’ into a virtual USB CD-ROM drive. It can also emulate a USB Floppy Disk drive.

Since it doesn’t come with a hard drive included, you can put your own 2.5in SATA drive in. I used an old 120GB SSD which makes for extremely fast installs of Windows, Linux, etc.

BitWarden (Open Source Rust Implementation) Debian Builds

You might have heard of BitWarden – a free/open source password management service that is a lot like LastPass.  I use it pretty heavily here thanks to the integration with various web browsers and iOS.

The original BitWarden server is kinda large and clunky.  A third party has re-implemented it in Rust with a much smaller footprint is API compatible with the official server.

As I’m not a fan of Docker, Bitwarden_rs was initially going to be a no-go for me due to it being distributed as a container by default.  However, another individual as nice enough to provide a build script and premade .deb files of it that doesn’t require docker to be installed.

The original build script author has been quiet since October, and there has been a few upgrades to Bitwarden_rs in the meantime leading to an outdated repo.  I’ve forked the repo on Github, updated the build script, and released updated .deb files for the latest upstream release.

Overview Of The Ubiquiti EdgeRouter Products

Since ~ 2012, UBNT has had their series gigabit capable routers, known as the EdgeRouter line.  There’s been a few generations of these over the years, focusing on either price or performance points.  It can be confusing when trying to find the best one to suit your needs, so lets do an overview of the different models and what they each bring to the table.

All of the ERs have pretty much the same software features, so we won’t go into too much detail on software unless its an important distinction.

First Generation (Cavium)
EdgeRouter Lite

This is the original EdgeRouter model – inexpensive (sub-$120 USD), capable of near wirespeed routing with its hardware offloading and accelerated IPSec VPN.  Has three gigabit ethernet ports, and can do various routing protocols such as BGP, OSPF, RIP, etc.

There are two versions of these – the original plastic ones and the newer metal case ones.  The original plastic ones have known issues with the DRAM and flash drives.

Old, but if you can find one cheap (either metal case, or a plastic one with the USB flash drive replaced), they make a great inexpensive CPE – however their CPU is pretty slow and anemic making for poor performance with OpenVPN, QoS, and other CPU bound uses.

EdgeRouter 5 POE

Basically an ERL with an integrated switch and passive 24v and 48v POE support (not 802.11af/at).  These can power an older Unifi AP that supports 24v passive, or some AirMax type devices.

Has same performance limitations as the ERL.

EdgeRouter 8

Rack mounted ER, faster CPU, and 8 gigabit copper ethernet ports.  Better performance with CPU bound applications/services such as OpenVPN and QoS.  Has all of the same software and offload capabilities as the ERL.

EdgeRouter Pro 8

Another rack mounted ER with a step up in performance from the ER8.  Has two SFP ports and six copper ethernet ports (two are shared).  Was top of the line performer for routing until EdgeRouter Infinity was released.

Although a solid performer, the ER8 and ERP8 are both outclassed by the newer ER4/6/12/Infinity models.  If you can find them inexpensively, they make a good router for sub-gigabit connections.

“1.5” Generation (MediaTek)
EdgeRouter X

This little router has a great price/performance ratio – for under $60 USD you get a 5 port router (built in switch) that is able to be powered over 24v passive poe, and is capable of outputting 24v passive for some Unifi APs.  Performance is almost equal to the ERL in many cases, with it performing better for some tasks like OpenVPN.

It does however have some limitations – offloading can be hit or miss performance wise, especially with the 2.0 firmware.  There is a single gigabit link between the internal switch and the CPU, which limits the theoretical max routing performance.  It also lacks a serial port, making it a pain to recover if you lock yourself out.

These units tend to be my ‘go-to’ for customers needing an inexpensive router while leaving room for future growth.

EdgeRouter X SFP

An ERX with an added SFP port and 24v passive POE on all five copper gigabit ports.

EdgeRouter 10X (new!)

An ERX with double the RAM, double the flash storage, and double the ports!  The 10 port integrated switch make this router a nice router/switch combo, perfect for small offices and home users.

This device somewhat straddles the older ERX and the newer ER4/6/12/Infinity line – not as good performance as the 2nd generation of ERs, but an improvement over the original ERX.

The serial port has been readded, and this device can only run the new EdgeOS 2.x software.

2nd Generation (Cavium)
EdgeRouter Infinity (AKA ER-8-XG)

UBNT’s first 10G router – 8 SFP+ ports and one gigabit copper.  16 CPU cores, 16GB of DDR4 RAM, and up to 80Gbps throughput.  This beast of a router was the first in the newest generation of routers, and packs quite a bit of performance in 1U.  It has dual PSUs.

The internal SFP+ banks can be quirky – they are split into two banks of 4.  If you want to run 1G SFP modules in some, you have to switch one bank (either 1-4 or 4-8) to being for 1G only.

For ~ $1850 USD, it’s not a bad price if you need > 1G performance.

EdgeRouter 4/6P/12/12P

UBNT’s newest line of routers – these are in the same CPU family as the Infinity, but are focused on 1G performance and price point.  Since they all have the same general performance, we’ll just point out the differences in what each offers hardware wise:

  • ER4 – Base model, 3 gigabit copper ports, 1 SFP port
  • ER6P – 5 gigabit copper ports, 1 SFP port.  24v passive POE on copper ports
  • ER12 – 10 gigabit copper ports (integrated switch), 2 SFP ports, 24v passive POE pass-through
  • ER12P – 10 gigabit copper ports (integrated switch), 2 SFP ports, 24v passive POE on copper ports

These units are optional rack mount, with a bracket kit available.  They are passively cooled, small form factor, in a durable metal case.

Configuring BGP On EdgeOS Devices

When you have your own IPv4/IPv6 address space, it’s advantageous to announce it via your router to your ISP – especially if you have multiple providers (multi-homing). Even the lowest end EdgeRouters such as the ER-X and ERL can do a full BGP table.

The prefix lists are used to control what routes you get from your ISP, as well as the ones you send (announce).

policy {
    prefix-list BGP-ISP-From {
        rule 10 {
            action permit
            le 24
            prefix 0.0.0.0/0
        }
    }
    prefix-list BGP-ISP-To {
        rule 10 {
            action permit
            prefix 192.0.2.0/24
        }
    }
    prefix-list6 BGP-ISPv6-From {
        rule 10 {
            action permit
            le 64
            prefix 0::/0
        }
    }
    prefix-list6 BGP-ISPv6-To {
        rule 10 {
            action permit
            le 48
            prefix 2001:DB8::/32
        }
    }
}

The -From prefix lists are for routes you receive (imported) from your ISP, while the -To lists are for routes being exported (announced) to your provider. In the case of IPv4, the smallest globally accepted size most if not all providers announce is /24. For IPv6, the smallest globally accepted size is /48.

‘le’ means any prefix smaller (ie: ‘le 48’ won’t allow a /64 IPv6 prefix from your ISP’s routing table, but it will allow a /32). ‘ge’ means any prefix greater (ie: ‘ge 56’ won’t allow a /48, but will allow a /56, /64, or even /128).

In the above examples, 192.0.2.0/24 is your IPv4 netblock, and 2001:DB8::/32 is your IPv6 one. 0.0.0.0/0 and 0::/0 means match all.

While you can just use prefix lists with BGP to control routes imported and exported, route maps give you much more flexibility and control, and can even include AS path matching.

policy {
    route-map BGP-ISPv6-From {
        rule 10 {
            action permit
            match {
                ipv6 {
                    address {
                        prefix-list BGP-ISPv6-From
                    }
                }
            }
        }
    }
    route-map BGP-ISPv6-To {
        rule 10 {
            action permit
            match {
                ipv6 {
                    address {
                        prefix-list BGP-ISPv6-To
                    }
                }
            }
        }
    }
    route-map BGP-ISP-From {
        rule 10 {
            action permit
            match {
                ip {
                    address {
                        prefix-list BGP-ISP-From
                    }
                }
            }
        }
    }
    route-map BGP-ISP-To {
        rule 10 {
            action permit
            match {
                ip {
                    address {
                        prefix-list BGP-ISP-To
                    }
                }
            }
        }
    }
}

Like the prefix lists, -To and -From are your specific directions in and out (import and export). They’re pretty self explanatory and reference the prefix lists used before.

protocols {
    bgp 65501 {
        address-family {
            ipv6-unicast {
                network 2001:DB8::/32 {
                }
            }
        }
        neighbor 100.64.100.1 {
            remote-as 65502
            route-map {
                export BGP-ISP-To
                import BGP-ISP-From
            }
            soft-reconfiguration {
                inbound
            }
            update-source 100.64.100.2
        }
        neighbor fd00::1 {
            address-family {
                ipv6-unicast {
                    route-map {
                        export BGP-ISPv6-To
                        import BGP-ISPv6-From
                    }
                }
            }
            remote-as 65502
            soft-reconfiguration {
                inbound
            }
            update-source fd00::2
        }
        network 192.0.2.0/24 {
        }
        parameters {
            router-id 100.64.100.2
        }
        redistribute {
            connected {
            }
            kernel {
            }
            static {
            }
        }
    }
}

In the above example, our local router has the IPv4 address of 100.64.100.2 and the IPv6 address of fd00::2 with an ASN of 65501. The BGP enabled router on our ISP side is 100.64.100.1 and fd00::1 with an ASN of 65502. We are assuming that our routers are connected over a non-shared link within one hop. If the BGP router is more than one hop away, you need to configure ‘ebgp-multihop’ with the appropriate amount of hops away your ISP’s router is.

[email protected]:~$ show ip bgp neighbor
BGP neighbor is 100.64.100.2, remote AS 65502, local AS 65501, external link
  BGP version 4, remote router ID 100.64.100.2
  BGP state = Established, up for 01w0d05h
  Last read 01w0d05h, hold time is 90, keepalive interval is 30 seconds
  Neighbor capabilities:
    Route refresh: advertised and received (old and new)
    4-Octet ASN Capability: advertised and received
    Address family IPv4 Unicast: advertised and received
    Address family IPv4 Multicast: received
  Received 2838376 messages, 0 notifications, 0 in queue
  Sent 20788 messages, 0 notifications, 0 in queue
  Route refresh request: received 0, sent 0
  Minimum time between advertisement runs is 30 seconds
  Update source is 100.64.100.1
 For address family: IPv4 Unicast
  BGP table version 6603726, neighbor version 6603716
  Index 2, Offset 0, Mask 0x4
  Inbound soft reconfiguration allowed
  Community attribute sent to this neighbor (both)
  Inbound path policy configured
  Outbound path policy configured
  Route map for incoming advertisements is *BGP-ISP-From
  Route map for outgoing advertisements is *BGP-ISP-To
  688930 accepted prefixes
  1 announced prefixes

 Connections established 1; dropped 0
  External BGP neighbor may be up to 1 hops away.
Local host: 100.64.100.2, Local port: 60803
Foreign host: 100.64.100.1, Foreign port: 179
Nexthop: 100.64.100.1
BGP connection: shared network

BGP neighbor is fd00::1, remote AS 65502, local AS 65501, external link
  BGP version 4, remote router ID 100.64.100.1
  BGP state = Established, up for 01w0d05h
  Last read 01w0d05h, hold time is 180, keepalive interval is 60 seconds
  Neighbor capabilities:
    Route refresh: advertised and received (old and new)
    4-Octet ASN Capability: advertised and received
    Address family IPv4 Unicast: advertised
    Address family IPv6 Unicast: advertised and received
  Received 686685 messages, 0 notifications, 0 in queue
  Sent 10394 messages, 0 notifications, 0 in queue
  Route refresh request: received 0, sent 0
  Minimum time between advertisement runs is 30 seconds
  Update source is fd00::2
 For address family: IPv4 Unicast
  BGP table version 6603726, neighbor version 6603716
  Index 1, Offset 0, Mask 0x2
  Inbound soft reconfiguration allowed
  Community attribute sent to this neighbor (both)
  0 accepted prefixes
  0 announced prefixes

 For address family: IPv6 Unicast
  BGP table version 858622, neighbor version 858620
  Index 1, Offset 0, Mask 0x2
  Community attribute sent to this neighbor (both)
  Inbound path policy configured
  Outbound path policy configured
  Route map for incoming advertisements is *BGP-ISPv6-From
  Route map for outgoing advertisements is *BGP-ISPv6-To
  49892 accepted prefixes
  1 announced prefixes

 Connections established 1; dropped 0
Local host: fd00::2, Local port: 179
Foreign host: fd00::1, Foreign port: 8044
Nexthop: 100.64.100.1
Nexthop global: fd00::1
BGP connection: shared network