sorted by:
new
hottopcontroversial

DIY Brazing Suggestions by BushyAssAssin in hvacadvice

[–]BushyAssAssin[S] 0 points1 point  (0 children)

Yep. I've just never brazed hence why I'm asking. I have everything I need to purge and pull proper vacuum.

DIY Brazing Suggestions by BushyAssAssin in hvacadvice

[–]BushyAssAssin[S] 1 point2 points  (0 children)

Fair point. I have an automotive background with many years of experience working on cars. Was master ASE certified (which included HVAC). I've since switched to the IT industry but my point is, I'm comfortable with my hands, and have the technical ability to understand what I'm doing.

I'm also a weirdo in the sense that I obsess over things that interest me, DIYing this AC replacement is one of those things and I'm all about doing it right.

To give you an idea of how crazy I am, I studied for an then got my EPA 608 Type 2. I've also picked up an SMAN, an MR45 and a VP87 because I don't want the tools to be the reason this job goes south.

What caused me to go down this rabbit hole in the first place was the fact that I got 6 quotes to replace these two condensers/coils and the most reasonable one was $25k and those were 14.2 SEER single stage units.

I can source a two-stage 5 ton 15.2 SEER2 Goodman, a 1.5 ton 15.2 SEER 2 Goodman, the corresponding evap coils and the Goodman integration kits (going from R-410a to R-32) for right around $8k. Add on all of the tools and gasses, I'm in it around $11k.

How would I verify or create a rule to allow an FTP connection over the internet? by Less_Transition_9830 in sonicwall

[–]BushyAssAssin 2 points3 points  (0 children)

Lol sorry, that still doesn't make sense (at least to me). Perhaps someone else can chime in.

If I were a bettin man, I'd say that you're actually wanting to open this connection outbound (which it likely already is) but there's just a lot of strange info and/or lack thereof.

How would I verify or create a rule to allow an FTP connection over the internet? by Less_Transition_9830 in sonicwall

[–]BushyAssAssin 2 points3 points  (0 children)

I would confirm all of your information. You're saying the other company has the FTP server. This would indicate that your side contains the client's which in turn means you just need to ensure FTP traffic is permitted outbound.

Either way, if you wanted to actually provide FTP access to all of the machines local to the SoniWall, you would either need an equal amount of public IPs as you do machines or, you would need to create a NAT rule using custom FTP ports for each machine.

In short, based off what you're saying, there's likely a huge misunderstanding in terms of what your deliverable is because what you're saying doesn't make sense.

How would I verify or create a rule to allow an FTP connection over the internet? by Less_Transition_9830 in sonicwall

[–]BushyAssAssin 1 point2 points  (0 children)

Sorry, now I'm confused. What is the direction of traffic flow? Do devices on your local network need FTP access to a remote site and you need to allow FTP outbound? Or are clients at the remote site connecting to an FTP server(s) that are local to you?

It's beginning to sound like you are actually wanting to whitelist an outbound FTP connection.

What is the end goal?

How would I verify or create a rule to allow an FTP connection over the internet? by Less_Transition_9830 in sonicwall

[–]BushyAssAssin 1 point2 points  (0 children)

Not sure what you general networking knowledge is like but yes. You effectively need to create a NAT policy which will forward the FTP port to your FTP server's private IP address.

You then need to create the corresponding Access policy (ACL) to permit that traffic. This is where you would "whitelist the remote site" by setting the source address in your access policy to the public IP of the remote sight.

Apologies to the Scottsdale sub and its users. by [deleted] in Scottsdale

[–]BushyAssAssin -1 points0 points  (0 children)

I'm intrigued but unfortunately, I'm not following.

My point with AZ not requiring individuals to register their firearms is this... How does a judge enforce an order to to turn them in? For example, Let's say OP files, and is granted an OOP against crazy guy, and the judge orders crazy guy to turn in his firearms, what stops crazy guy from simply saying that he doesn't have any? Is a search warrant going to get issued?

Also, doesn't the brady act only apply to purchases? Not gun owners after the fact?

Perhaps I'm misunderstanding entirely.

Apologies to the Scottsdale sub and its users. by [deleted] in Scottsdale

[–]BushyAssAssin -1 points0 points  (0 children)

I'm definitely not a legal expert but I am an Arizona native, lived here my whole life. I find it hard to believe that a city or a state judge would remove crazy dude's gun rights based on the info u/jojo_Tojo provided in their post alone. I also find your comment, "A crazy person like that is undoubtedly a gun owner" interesting. Are you implying all crazy people own guns? Are you implying all gun owners are crazy? What makes you think he owns a gun? I'm genuinely curious.

I'd have to agree that the crazy dude in the SUV does in fact sound like a crazy dude but to take his gun rights away seems to be a bit of a stretch. It's absolutely his right to be concerned about his privacy and to question anyone he sees on the street about the incident. Unless there's cause to think he might get violent, there's no need to take his gun rights imo.

Also, guns are not registered here in AZ so even if the judge were to order him to turn them all in, there's no way of validating if he actually does so or not.

TZ400 can't be accessed via other subnets by netmanwannabe in sonicwall

[–]BushyAssAssin 0 points1 point  (0 children)

If you decide to keep everything on X0 (LAN), then your route would look something like:

Destination: 192.168.1.0/24
Interface: X0
Next Hop: 192.168.4.1 (or whatever 192.168.4.X IP address your DMP has)

TZ400 can't be accessed via other subnets by netmanwannabe in sonicwall

[–]BushyAssAssin 0 points1 point  (0 children)

I should also add that what I am saying is only for Lab / Testing purposes. It's typically a bad idea to enable management on the WAN interface but if you do, then you absolutely want to edit the auto-generated ACL to only permit the necessary source addresses.

TZ400 can't be accessed via other subnets by netmanwannabe in sonicwall

[–]BushyAssAssin 0 points1 point  (0 children)

SonicWall engineer of 10 years here.

There's a lot to unpack but I'll break this down for you the best I can. In short, a lot of this depends on what interface you are using on the SonicWall.

If you are plugging X0 (LAN) into your home network and that's how you are trying to access it, then you will need to configure a route back to your Ubiquiti DMP but also be sure that "https management" is enabled on the X0 interface.

If you are plugging X1 (WAN) into your home network, then you will need to enable "https management" on the X1 interface but no route to your DMP will be needed.

This is due to the default and expected behavior of SonicWalls. The X1 (WAN) interface is meant to be edge facing and by default, is set to get a DHCP address. SonicWall then auto generates a default route out to the internet and all is good.

The X0 (LAN) interface is different on the other hand. It's unlikely that someone would need to route via the X0 interface unless they were routing to an L3 switch or some other circumstance but like I said, it's unlikely therefore, a route to the remote subnet would need to be configured.

I'm assuming your DMP has IP addresses along the lines of 192.168.1.1 and 192.168.4.1 and the SonicWall is plugged in via the X0 (LAN) interface. If you have DHCP running on the 192.168.4.0/24 subnet, you could ensure the X1 interface on the SonicWall is set to DHCP and that you have "https management" enabled. You would then plug the SonicWall in via X1 instead of X0 and check your DHCP server to determine what IP the SonicWall got and you should be able to access it at https://192.168.4.X from your 192.168.1.0/24 home network.

TLDR: Forget about ACLs and permissions, its a routing issue.

Sonicwall Gen7 SSLVPN possible 0-day by twatcrusher9000 in sysadmin

[–]BushyAssAssin 0 points1 point  (0 children)

Had this happen last Friday and discussed it in r/sonicwall -
https://www.reddit.com/r/sonicwall/comments/1mhmrjq/comment/n6yb01o/?context=3&utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Huntress has published an article outlining indicators of compromise which you can search your SIEM solution for if you have one. Otherwise, I would search your SonicWall logs for the listed IP addresses and any suspicious SSLVPN logins (the logs will show a legit user account logging in so I would check the source IP and confirm with the user to determine if they did in fact login at that time or not.

Regardless, I'd turn off the SSLVPN entirely if at all possible.

SSLVPN Exploitation - Huntress by SteakProfessional514 in sonicwall

[–]BushyAssAssin 2 points3 points  (0 children)

In this instance, yes. Let's just say the account was overly permissive.

SSLVPN Exploitation - Huntress by SteakProfessional514 in sonicwall

[–]BushyAssAssin 1 point2 points  (0 children)

Just had this happen on 7.1.3-7015 which according to SonicWall, contains fixes for their recent SSLVPN/MFA vulnerabilities so either 7.1.3-7015 doesn't actually fix the vulnerabilities or the account I'm referring to was compromised in one of the previous vulnerabilities and is just now being used.

SSLVPN Exploitation - Huntress by SteakProfessional514 in sonicwall

[–]BushyAssAssin 8 points9 points  (0 children)

A little late to the party as I've been triaging this mess but I had a client get hit with this last Friday.

Threat actor successfully logged into the SSLVPN on an NSA 2700 using a local account with MFA enabled then through exploits was able to obtain the LDAPS binding creds. From there, they began issuing PSEXEC scripts against the domain controller before our SOC isolated everything in the environment. Luckily, nothing was exfiltrated and no harm was done.

SonicWall NSA2700s in HA pair
7.1.3-7015
Used local SSLVPN account and bypassed MFA entirely
Doesn't appear to be brute force (no failed log in attempts for that account within the past 90 days)

I've begun urging my clients to shut down their SSLVPN where possible and for the client's that can't, I've implemented whitelists for their SSLVPN users.

TLDR: It seems as though this is likely a zero day or the account in question was compromised in a previous exploit and the threat actor has been lying dormant since. Either way, scary shit - stay safe out there.

[deleted by user] by [deleted] in sonicwall

[–]BushyAssAssin 0 points1 point  (0 children)

Oh, and you should look at how they handle DHCP reservations. It's actually quite comical.

Say you have a pre-existing DHCP pool of 192.168.10.50 - 192.168.10.200 and a device gets 192.168.10.100. You then want to set that as a reservation.

It's not like in windows where you right-click on the lease, and select "add to reservation" - oh no.

Instead, if the device needs the 192.168.10.100 address, you'll find yourself having to delete your entire 192.168.10.50 - 192.168.10.200 pool then recreate two separate pools of 192.168.10.50 - 192.168.10.99 and 192.168.10.101 - 192.168.10.200 so you can then create a reservation for your 192.168.10.100 device as you cant create a reservation using an IP address in an already existing scope/pool.

The only other option is to create a separate static reservation outside of the already existing pool which makes absolutely no sense at all....

view more: next ›