|
I'm starting to think you just struggle with the definition of the word "add". How is MFA relevant to the conversation?
|
#
?
Sep 3, 2019 03:37
|
|
|
|
| # ? Apr 27, 2024 23:17 |
|
|
just a question from ignorance, but is a secret pattern not a password? or is that too reductive?
|
|
#
?
Sep 3, 2019 03:37
|
|
|
Jabor posted:I'm starting to think you just struggle with the definition of the word "add". How is MFA relevant to the conversation? How does it not? If we're going to second guess industry standards, then we might as well quit the field because apparently all the other Infosec groups thinks defense in depth and things like MFA are adding security. infernal machines posted:just a question from ignorance, but is a secret pattern not a password? or is that too reductive? Yes. But given that all it gains you in my admittedly overly complex schemes is an exposed port, and it rotates, it largely just because one day I wanted to play with port knocking without risking it as a single authentication method. CommieGIR fucked around with this message at 03:42 on Sep 3, 2019 |
|
#
?
Sep 3, 2019 03:39
|
|
|
CommieGIR posted:How does it not? If we're going to second guess industry standards, then we might as well quit the field because apparently all the other Infosec groups thinks defense in depth and things like MFA are adding security. If you absolutely need MFA type protection for ssh based on your threat model, you can just have your private key in a smartcard or whatever.
|
|
#
?
Sep 3, 2019 03:43
|
|
|
No serious infosec person thinks my rosary-based scheme adds any security, and similarly no serious infosec person thinks your port knock scheme adds any security. The nature of addition is such that it doesn't matter what other schemes you have behind your port knock - they're not relevant to a discussion of whether your port knock scheme adds any extra security.
|
|
#
?
Sep 3, 2019 03:43
|
|
|
CommieGIR posted:I'll gladly go back to lurking, sorry thread. Thanks
|
|
#
?
Sep 3, 2019 03:45
|
|
|
Jabor posted:No serious infosec person thinks my rosary-based scheme adds any security, and similarly no serious infosec person thinks your port knock scheme adds any security. I'm not a serious infosec person then. See yah.
|
|
#
?
Sep 3, 2019 03:45
|
|
|
last of these for tonight I promise.  
|
|
#
?
Sep 3, 2019 03:54
|
|
|
CommieGIR posted:I'm not a serious infosec person then. See yah. this can be an actual educational discussion if you and Jabor break down your arguments in more detail, instead of you bailing!
|
|
#
?
Sep 3, 2019 03:59
|
|
|
Beamed posted:this can be an actual educational discussion if you and Jabor break down your arguments in more detail, instead of you bailing! Id love to. But frankly, given that it turned into ad homs about by profession, and then comparing actual auth methods to prayers, I dont really see much point.
|
|
#
?
Sep 3, 2019 04:05
|
|
|
I apologize if I've been a bit antagonistic - from my perspective, I've asked you to explain why you think port knocking is useful, and you've largely ignored that and reacted as if I've been criticising the entire concept of authentication. Why do you think port knocking is helpful and adding security, as compared to a hypothetical system that's exactly what you have now, but without the port knocking?
|
|
#
?
Sep 3, 2019 04:14
|
|
|
Jabor posted:I apologize if I've been a bit antagonistic - from my perspective, I've asked you to explain why you think port knocking is useful, and you've largely ignored that and reacted as if I've been criticising the entire concept of authentication. Having a port only open when it's in use helps protects against a theoretical unpatched sshd preauth RCE I guess.
|
|
#
?
Sep 3, 2019 04:22
|
|
|
Jabor posted:No serious infosec person thinks my rosary-based scheme adds any security, and similarly no serious infosec person thinks your port knock scheme adds any security. Somebody better tell Moxie this
|
|
#
?
Sep 3, 2019 04:27
|
|
|
Jabor posted:I apologize if I've been a bit antagonistic - from my perspective, I've asked you to explain why you think port knocking is useful, and you've largely ignored that and reacted as if I've been criticising the entire concept of authentication. Because exposing SSH is generally frowned upon. Most companies will look at you funny if you ask the Networking team to expose an SSH port publicly, security of RSA or not. I try to eat the dogfood I sell my clients, which is do not expose SSH if at all possibly, if you need SSH, require a jumpbox/VDI or VPN. I only use my SSH if the VPN has failed, or my hypervisor has alerted me of a heartbeat failure, usually because we had a power failure for more than an hour. So I'm only opening SSH externally in emergencies. I try to keep a clean public port/firewall profile as well, so no extranious ports open. Even the ports I knock are closed. Hell, I disabled root accounts on all my lab boxes and personal machines to try to do better housekeeping internally, and re-enabled SELinux to get used to it. I never suggest port knocking to my clients, its a kludge just for me because I dont have any out of band access. I liked how it worked, so I kept it. Google MFA is just turned on by default on my internal LDAP, so any *nix devices I have use it, so even with a public key it'll challenge you. I also partially did it because I had a malware I was analyzing in Cuckoo try to break out of the VM, so I got a little paranoid.
|
|
#
?
Sep 3, 2019 04:27
|
|
|
Can you be more specific than "generally frowned upon"? I get that that's probably sufficient for your clients (since you're the professional and they don't really need to understand it beyond implementing your recommendations), but this discussion is for the benefit of people who really do want to understand why something isn't good. Or is it just because clients tend to have IT guys who think it's bad without any real reason behind it, and you just have to play along?
|
|
#
?
Sep 3, 2019 04:35
|
|
|
I think its usually because they are the sort who have not disabled the root ssh access for....reasons. Usually when I ask why I get a runaround. Even better when the root password is dictionary, they dont have logging audited, and its bruteforce friendly
|
|
#
?
Sep 3, 2019 04:48
|
|
|
So it's not bad if done right, it's just often done badly? And so people would rather not do it at all since that's easier to enforce than saying "don't do it badly"?
|
|
#
?
Sep 3, 2019 04:52
|
|
|
There's always more lurking in most enterprise infrastructure. Especially since most dont operate clean environments, and often have mixed bags of kernels, patches, and questionable dev/test environments on flat unsegmented networks. So yeah, its usually because cleaning the environment will take more than just warning them not to expose SSH. Suggesting Re-architecting the network usually gets laughs CommieGIR fucked around with this message at 05:07 on Sep 3, 2019 |
|
#
?
Sep 3, 2019 05:02
|
|
|
Look, port knocking is dumb because if I'm on the same network as you, which can easily happen if say we're at the same Starbucks and I arp spoof the gateway, or I'm on your router because Comcast or whoever has lovely cheap vulnerable crap, or I'm a nation state tapping your poo poo, or I'm at any of the networks in between you and the server, or for any myriad of reasons, then the port knocking sequence is no longer a secret. You have to expect the network between you and your server to be compromised somehow at some point in between. That's precisely why we even use authentication and encryption. Might as well use telnet otherwise. So, that's why, your port knocking doesn't add anything on top of the security you already have which is encryption, public key authentication and MFA with Google authenticator. You kept going on about how your poo poo is secure because defense in depth and etc, but really it doesn't add anything.
|
|
#
?
Sep 3, 2019 06:36
|
|
|
Also if you genuinely don't understand how a port knocking sequence is a de facto password sent in the clear over the network, you don't have a clear enough mental model to be making decisions about security imo
|
|
#
?
Sep 3, 2019 06:47
|
|
|
Rufus Ping posted:Also if you genuinely don't understand how a port knocking sequence is a de facto password sent in the clear over the network, you don't have a clear enough mental model to be making decisions about security imo that’s a bit harsh I’ve seen dumber people making decisions that actively harm their efforts to secure the thing they want or just completely break the usability. whereas port knocking is in the realm of a security through obscurity doesn’t hurt, just don’t make it your only means of protection.
|
|
#
?
Sep 3, 2019 07:00
|
|
|
I stand by what I wrote. Port knocking belongs in the dustbin of the early 2000s and it's a bit of a 'tell' when someone recommends it. The scenarios where it confers an actual benefit are pretty contrived, and all require that something else isn't being done properly. Out of curiosity CommieGIR, do you exclusively knock using UDP or have you granted your knock (hping, nmap, etc) client CAP_NET_RAW?
|
|
#
?
Sep 3, 2019 07:44
|
|
|
port knocking is cool just like secret handshakes are cool: when you're 11 years old
|
|
#
?
Sep 3, 2019 08:02
|
|
|
I just went and read what port knocking is and is this Seinfeld or yospos?! Holy poo poo did someone really use such a convoluted idea in real world? Don't take security advice from knockers, y'all! Above there was text about WireGuard. As I recently did some trials of it, I paste you my writeup here (minus formatting because). TL;DR: it works well, except on Windows it doesn't work in server mode; there's literally zero logs, if it doesn't work just roll dice to try to unfuck; there's also no DHCP or equivalent. --------------------- WireGuard is a modern VPN technology. This page is a quick start that actually works (plenty of WireGuard quick starts on the web are incomplete). The technology is under active development but already usable in many situations and superior to legacy technologies in various ways. ## Basic principles There is no "server" and "client" in terms of software. Any WireGuard installation can connect to any other WireGuard installation. There may be a "server" in terms of establishing connectivity - at least one of the peers must have an open port for the other to connect to, in each pair of WireGuard installations. The other does not need an open port (it will be opened using NAT). In fact, even if a peer's IP address changes (e.g. switching between mobile data and wifi) the tunnel will automatically reconnect and resume with the new IP address. There may be a "server" in terms of whether a WireGuard installation will route traffic from a remote peer into the local network or not. Authentication is performed using key pairs. IP address assignment is static, making WireGuard suitable for "hardwired" connections and less suitable for arbitrary "on the fly" connections. WireGuard works on most operating systems, though Windows is the most alpha quality of them all. ## WireGuard network adapters Everything focuses around configuring one or more WireGuard network adapters. These are what enable connectivity between machines. Depending on operating system, a WireGuard network adapter may also be called a "tunnel", though in fact a network adapter can consist of several connections/tunnels. The language is a bit vague at times. How it works is that on any WireGuard installation you can define 1 or more WireGuard network adapters. Then each of these network adapters can connect to 1 or more other WireGuard installations. The most common situation might be 1-to-1 links but 1-to-100 is perfectly doable, as well. Each set of connected WireGuard network adapters creates a new virtual network. By default, the WireGuard enabled machines can only talk to each other. However, you can configure a machine to also forward traffic into the local network (or the internet), making it act as a router that connects the virtual network to a local network. ## Setting up a WireGuard network adapter On Ubuntu 16 and Ubuntu 18: code:On Windows, the equivalent process is: code:IP forwarding on Windows does not work well with WireGuard as of version 0.0.20. If you want to grant remote peers access to the local network, use an Ubuntu based installation. ## Configuring a WireGuard network adapter Prerequisites: code:There is a separate configuration file for each adapter. It is structued in INI file format. The contents are mostly the same on Windows and Linux. Inline comments in the following example configuration file explain the details. Example configuration deliberately uses incorrect IP addresses to ensure you remember to update: 111.222.333.444 is the public IP address of the listening side, port 9090. 900.900.900.0/24 is the WireGuard network range, with the listener assigned .1 and the connecting side assigned .2 Listening side code:code:0.0.0.0/1, 128.0.0.0/1 Do not use 0.0.0.0/0 as that would enable WireGuard kill-switch logic that is unlikely to be useful. On Ubuntu, to direct forwarded traffic into a WireGuard tunnel (e.g. because it is a tunnel to the internet), use the following under [Interface] section: PostUp = iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE PostDown = iptables -t nat -D POSTROUTING -o wg0 -j MASQUERADE Adjust wg0 to match the outgoing adapter name to the current adapter. NB! This only sets up NAT and assumes that IP forwarding is already enabled. ## Establishing a connection A WireGuard network adapter is always working after it is activated by the relevant command. However, this does not mean that it is always connected to the other end. WireGuard will always try to be connected 24/7 but if something disrupts the link, it will just drop any packets going into the WireGuard network. There is a "latest handshake" counter in the Windows GUI that appears once connectivity is established. To see equivalent output on Linux, do "sudo wg". If the handshake information does not appear or indicates more than a few minutes in the past, it is likely that connectivity is not present. ## Applying changes To apply configuration changes, execute: wg-quick down wg0 && wg-quick up wg0 ## Troubleshooting There is no logging or anything. If it doesn't work, just try different things until it does. EssOEss fucked around with this message at 08:53 on Sep 3, 2019 |
|
#
?
Sep 3, 2019 08:51
|
|
|
public ssh server chat: you can do pubkey + google auth and there is now functionality that allows caching by source so you don't have to punch the authkey in every time. As long as you stay on top of your security updates then I don't think all the other port-related obfuscations are necessary.
|
|
#
?
Sep 3, 2019 10:53
|
|
|
I know a company that ran all SSH services on a different port from default, but they understood that this added no security. All this achieved was making the log files more legible. They couldn't use fail2ban because they'd locked themselves out once, and management consequently forbade it. 
|
|
#
?
Sep 3, 2019 11:14
|
|
|
i won't standby while port knocking's reputation is tarnished! it's great for comedy ctfs where the box only lets you in after a portscan i've said it before but tool disruption boxes are hilariously effective. the challenge can be "connect to this box, here's the credentials" and there'll be a stonewall if you disrupt the normal workflow with as much as "your portscan returns every service ever made"
|
|
#
?
Sep 3, 2019 11:25
|
|
|
CommieGIR posted:I think its usually because they are the sort who have not disabled the root ssh access for....reasons. Usually when I ask why I get a runaround. Even better when the root password is dictionary, they dont have logging audited, and its bruteforce friendly I generally don't like a pile-on, but I want to call you on this. Previously you described your approach as a kind of belt and suspenders "defense in depth," thing, but now you're kind of moving the goal posts by saying you're actually advocating these things as frontline security measures to make up for core deficiencies. SSH is not incredibly hard to secure as services go. It's very important to configure it properly so that it is secure because of what it can do, but the strategies for hardening are all very straightforward. I've only set up a couple VPN systems in my career, but I gotta say that it seemed much easier to gently caress up than all the times I've set up SSH with key-only, whitelisting the good ciphers, whitelisting the only non-root accounts that need access, blacklisting root, and firewalling it so it's only accessible from wherever it needs to be accessed from. Your answer to hosed up configuration of network services can't be more network services. Looking at it logically, you're literally just increasing the attack surface. On some level something has to be configured properly for any of this security to work. ErIog fucked around with this message at 11:42 on Sep 3, 2019 |
|
#
?
Sep 3, 2019 11:33
|
|
|
 Welp. I gotta internalize your criticism, you guys do have some very valid points. Still feels like a gut punch, but peer review often does. I'll roll with it.
CommieGIR fucked around with this message at 13:38 on Sep 3, 2019 |
|
#
?
Sep 3, 2019 11:40
|
|
|
Cocoa Crispies posted:
judge Dredd's gun but its authentication to post
|
|
#
?
Sep 3, 2019 12:51
|
|
|
Cocoa Crispies posted:y’all just lucky fbook hasn’t started using liters of blood for identity verification i heard you can do it with just a finger stick now
|
|
#
?
Sep 3, 2019 13:21
|
|
|
flakeloaf posted:i heard you can do it with just a finger stick now gtfo with this homeopathic bullshit
|
|
#
?
Sep 3, 2019 13:35
|
|
|
flakeloaf posted:i heard you can do it with just a finger stick now elizabeth holmes alt account found
|
|
#
?
Sep 3, 2019 14:20
|
|
|
the wg writeup is great, thanks!
|
|
#
?
Sep 3, 2019 16:17
|
|
|
flakeloaf posted:i heard you can do it with just a finger stick now *extremely elizabeth holmes voice* nanotainer
|
|
#
?
Sep 3, 2019 16:33
|
|
|
https://twitter.com/BulletinAtomic/status/1168306294702432256
|
|
#
?
Sep 3, 2019 16:35
|
|
|
Oh man. No. Too many flashbacks to NORAD and Soviet near misses.
|
|
#
?
Sep 3, 2019 16:39
|
|
|
Can't wait for the 2020 version of that ai Google doc with the row Algorithm figured out that nuclear war could be prevented by preemptively nuking Russia and relying on the opponent expecting a false positive warning.
|
|
#
?
Sep 3, 2019 17:01
|
|
|
that WG writeup is very good I wonder if the no-dynamic-addresses thing is a big deal for me given how rarely my address changes (hasn't happened in the year I've had service). how hard is it to do the address update? maybe I could automate it alongside the dynamic DNS updater re: ssh, I run my externally-accessible ssh on a different port so that my log files don't end up full of kiddie scan messages, numbing me. I'm also going to set up a push notification via home assistant to tell me when someone sshs in, I think has anyone used nginx in reverse-proxy mode to put MFA in front of arbitrary web apps? it looks possible, but everything I find looks a bit rickety
|
|
#
?
Sep 3, 2019 17:01
|
|
|
|
| # ? Apr 27, 2024 23:17 |
|
|
Sereri posted:Can't wait for the 2020 version of that ai Google doc with the row learns to pair launch with an urgent message to Russia that there was an accidental launch but there are no payloads
|
|
#
?
Sep 3, 2019 17:02
|
|