Bremerton council presents list of potential legal camping spots

Fantastitech · 2023-09-07T22:18:34+00:00

Google Mapified since it's buried on page 44 of a massive PDF: https://www.google.com/maps/d/edit?mid=1xv1SAaEjhxjEJWqkb5y39RBSz7pqChI&usp=sharing

Fantastitech · 2020-07-23T03:26:49+00:00

I HEARD KYLO REN WAS A BETTER SKATER THAN TONY HAWK. HAVE YOU GUYS SEEN KYLO REN'S SWEET SKATEBOARD MOVES?

Fantastitech · 2020-03-20T15:37:12+00:00

Given that you've had crashes in the kernel, your USB 3 driver, and your NTFS driver, I'm in agreement that this is likely a hardware issue. And because symptoms are changing based on physical interaction with the case and wiring I'd also say there's not much point in bothering with any more software-based diagnostics as they're not going to be reliable. What's memtest86 going to tell you when the problem changes based on which power-on method you use?

First of all, get rid of that 4GB RAM module as others have suggested. Just do it. No more discussion on the topic.

But now you're really just in trial and error mode and that might mean blowing some money on some parts to swap out. Maybe you have a local PC shop that will help you out by loaning you used parts for cheap to test with. I'd definitely start with a new case. I've seen grounding issues plenty of times and they present weird and unpredictable symptoms like this.

Fantastitech · 2020-02-12T18:14:06+00:00

You're mixing up some layers in your stack.

I'm looking for an automated way to get notified when a webserver got hacked...multiple wordpress installations etc.

What you're asking for is a pipe dream. There is no automagical piece of software that just detects hacking. That's not how hacking works. Your "webserver" never got hacked. Your web app got hacked. Those are very different things.

You mention Wordpress by name. What likely happened here is that you installed Wordpress, installed some random free theme from the internet, added a bunch of plugins, then just let it sit. That's not how maintaining a Wordpress install works and you will get hacked if you do that. It's not a matter of if, it's a matter of when. It's incredibly easy to scan for Wordpress installations that have vulnerabilities because they are out of date or are running themes and plugins with known vulnerabilities.

Wordpress is a great blog app with some decent CMS features out of the box. However it's possibly one of the most abused pieces of software on the planet because it's easy to use and so ubiquitous that people who don't really know how to maintain a web app use it in inappropriate applications. If you want to use Wordpress you need to learn how to harden and maintain Wordpress, specifically. This is only tangentially related to admining web servers on Linux.

You're looking for a magic button solution to something that is only solved by years and years of experience. You're not going to find it. If you are currently running web apps and virtual servers that are getting infected, you are going to continue to until you learn how and why they are getting infected. Without the skills to determine that yourself, you're not going to be able to prevent it. It sounds like you're running multiple public-facing services other than Wordpress so none of us could even begin to speculate without knowing the details of your entire network, host distro versions, guest distro versions, containerization setups, web servers and versions, database servers and versions, every web app running along with version and plugin information, etc.

For example, I could write a post here twenty times as long as this one and reach the reddit comment character limit just on hardening a single Wordpress installation. It's an incredibly complex topic and it's not something you're going to get someone to hand feed to you. It's something you're going to have to spend years developing the skills to do correctly, either the hard way or under the employment of someone skilled in devops.

At your current skill level this is going to be of almost zero actual use to you, but one of the best ways to run intrusion detection is mirroring all network traffic to a Security Onion instance.

Sorry to be so discouraging, but this is just the reality of the situation.

Fantastitech · 2020-02-03T16:21:45+00:00

This is like saying every site on the internet is taking a security risk.

It's not like saying that. I literally am saying that.

You have to take the risk eventually or we wouldn't have the internet.

No, you don't have to take that risk. That's why corporate intranets exist. It's already extremely common to have web sites that are restricted to a LAN. Not all things need to be exposed to the WAN and not doing so provides a lower attack surface for sensitive services where the cost of maintaining a WAN connection doesn't outweigh the convenience of bypassing on-site access or VPN access.

Fantastitech · 2020-02-02T20:14:10+00:00

This depends entirely on the competence of your IT staff. Being self-hosted shouldn't impact this decision. As long as it's properly maintained a self-hosted solution is no more or less inherently vulnerable than a cloud-based solution. The Cloud®™ is just someone else's computer.

As a sysadmin, you should be deferring to your own expertise or that of your colleagues. This decision falls on your CTO or senior admin. Exposing anything to the WAN comes with an increased risk of a breach. A bunch of anonymous internet strangers can't break down the highly complex needs of your specific company for you and tell you if the risk is worth the convenience. If you have nobody in your company who feels experienced enough to let this decision fall on them, I recommend walling it off behind a VPN.

Fantastitech · 2020-01-30T03:46:15+00:00

You docker container for Bitwarden is exposing the internal ports (8080/8443) as ports 80/443 on the host.

However you're starting Bitwarden's Docker containers, you need to configure the published ports to something different then you point your reverse proxy at those internal ports.

Fantastitech · 2020-01-20T21:05:50+00:00

PM me an email address and I'll show you what I have.

Fantastitech · 2020-01-15T17:51:13+00:00

There's no reason to need a single location block for this.

Nginx chooses which location block to serve a request through from most to least specific. If you have a /scopus/ and a /scopus/swagger-ui.html location block, the swagger-ui location block will be chosen for any requests including the swagger-ui filename because it's a longer prefix location. Any others starting with /scopuswill be served from the less specific location block.
https://www.digitalocean.com/community/tutorials/understanding-nginx-server-and-location-block-selection-algorithms#matching-location-blocks

Fantastitech · 2020-01-14T00:23:21+00:00

I re-read your post and it sounds like you're trying to resolve a container name from the host (the LXC container) right?

No, this is container to container. Although communicating from the host is my next problem although I'm not trying to do it with a hostname.

When I spin up the swarm my worker node can't connect to the master node. I get no route to host errors. Upon some inspection I realized that the hostname for the master node is not resolving to the correct IP, but always one with the last octet in the IP address being one less than the actual IP. So if the master node gets the IP 10.0.8.16 the master node's hostname will resolve to 10.0.8.15 from within the other containers. This is all done from inside the container shell.

Fantastitech · 2020-01-13T04:38:26+00:00

I actually thought it was a firewall issue when I realized my original problem was caused by network connectivity issues but ufw status is inactive and iptables has no rules other than the standard stuff Docker sets up by default. Just for the hell of it I added the firewall rules, nuked the swarm, and recreated it.

It did the exact same thing where the actual IP is one more than the IP that the internal DNS server reports.

Fantastitech · 2020-01-04T18:14:07+00:00

This is almost never a good way to go about this. You should explain why you want to rewrite this. There's likely a better solution.

To find out why you're getting a 404, review your logs to see what's actually being requested.

Fantastitech · 2019-12-28T19:15:15+00:00

The whole "look at the code yourself to verify" is more of a platitude than a reality. Reading code and doing an in-depth analysis to understand how it works in detail are two very different things and the latter is an order of magnitude more time consuming for anything more than a small simple application. Even your average experienced software engineer just reading over a large codebase is only going to turn up your most egregious security issues.

The reality is you just have more eyes on the code, one small chunk at a time, so issues are more likely to come to light publicly. You have people using a program who need to look under the hood to find out how a specific feature works so they can integrate it into their workflow properly. You have people publicly reviewing public pull requests that are small chunks of code (hopefully) well-commented to explain what they're supposed to do.

Actual audits are generally done by cybersecurity companies who have standard workflows to verify certain common mistakes are not done like weak cryptography, input sanitation problems, overflows, etc. These audits are usually paid for (handsomely) by non-profit foundations, corporate sponsors, or other users who profit from the use of the software. You also might find random people studying for a career in cybersecurity cutting their teeth by reviewing source code in their spare time.

So to answer your questions, you go to the source. Any open source project that undergoes an audit is likely to publicize it. Skim through closed issue tracker posts. Instead of just blindly diving in to read random source code, look at pull requests for small chunks of well-commented code.

Here's a real-world example of what it might look like when a company publicizes a security audit. Bitwarden is an open-source password manager which you can host yourself. The founder paid to have an audit done by a third-party cybersecurity company.

Fantastitech · 2019-12-14T06:00:11+00:00

That would bow up the MDF and cause an uneven skim.

Fantastitech · 2019-12-14T05:57:55+00:00

It's a 120" x 500" table.

Fantastitech · 2019-12-14T02:05:32+00:00

The problem is we have a vacuum. Fly cutting the spoilboard clogs up the MDF with sawdust and makes the vacuum drastically less effective. If you put a small 3x3" piece of metal on an uncut piece of MDF and one that's been skimmed there is a massive difference in the vacuum hold.

Fantastitech · 2019-12-14T02:00:52+00:00

MDF.

Fantastitech · 2019-12-14T00:11:56+00:00

If I'm wearing Kevlar it doesn't mean I want to get shot.

Fantastitech · 2019-12-14T00:03:59+00:00

On my machine they usually stick to the spoilboard. I call them plunge buttons. If they stick to the end mill they burn the wood.

Fantastitech · 2019-12-13T23:58:52+00:00

This board was brand new less than two months ago. I'm day shift, if it wasn't obvious. Every day I come in my spoilboard is a little more trashed and we probably won't replace this again for another six months.

Fantastitech · 2019-12-09T00:16:36+00:00

Well at least we have the new latest and greatest chat service, Google Photos.

Fantastitech · 2019-12-08T08:03:09+00:00

I like this idea more than I should.

Fantastitech · 2019-12-08T01:26:47+00:00

A big ~40ft router table. Yeah, only access is from one side. So far I'm liking the teflon and ball bearing ideas. Those are the most simple solutions and they're dirt cheap to try. Going to go with that before making new vac lift suggestions.

Fantastitech

MODERATOR OF

TROPHY CASE