Please wait...
Then i would go with option 2, or something similar. Waste the bandwidth or other resources for the sake of stealth.
Once upon a time due to a lot of restrictions, and similar 'performance' annoyances issues, i ended up doing a p2v so i could run the office computer on better/larger hardware, in effect. I have a ( office bought ) MSDN license, so changing hardware the first time didnt burn me. ( later when we started staying home a day or 2 a week, pre pandemic, i redid the office laptop as a host. just shuffled the vm back and forth when i had to come into the office ) May not work for everyone tho..
Sat Aug 05 2023 09:48:19 AM EDT from zelgomerDo they pay you for after hours? If not id say f-it and find
something else to keep yourself occupied at night. Get a hobby.
Okay, but for the sake of argument only, let's say it was to be used during normal work hours too :)
So this person devises a back door using ssh tunnelling over stunnel
(required to diguise the traffic as https because the company's
If the internal network is run by people who love security theater, they're going to catch and terminate this person eventually, so it isn't worth it.
Get an A/B switch, plug the company laptop into the big monitor, attach it to a separate VLAN on the home network, and deal with the slow VPN.
There's probably something in their company security policy that specifically prohibits trying to work around the VPN using any sort of trickery. My employer definitely has that policy in place, and they actively scan end user workstations for software that could work around it.
And then they blow the whole thing by permitting users to log in to Microsoft 365 from any computer.
Between that and us moving to a new ITSM platform, i may never need windows or a shop PC again.
Sat Aug 05 2023 11:22:57 AM EDT from IGnatius T FoobarAnd then they blow the whole thing by permitting users to log in to Microsoft 365 from any computer.
2023-08-05 15:22 from IGnatius T Foobar <ajc@citadel.org>So this person devises a back door using ssh tunnelling over stunnel
(required to diguise the traffic as https because the company's
If the internal network is run by people who love security theater,
they're going to catch and terminate this person eventually, so it
isn't worth it.
Yeah, 100% agree. That's what I would say to this hypothetical person, too.
But let's say you wanted to catch people doing this. As an IT/security person, how would you notice it short of scanning specifically for ssh -R processes? ssh use is allowed where I work, it has to be. We're all using it pretty much constantly.
I would do all of the following:
1. Block all outbound DNS lookups, except through the corporate DNS server
2. Configure that DNS server to use OpenDNS or some similar service that scans, logs, blocks, etc.
3. Force all outbound HTTP/HTTPS traffic through a proxy
4. Configure all workstations to trust a certificate that is installed on the proxy, permitting it to be a man in the middle for approved traffic
Now, if you're legitimately performing outbound SSH to external addresses, that is somewhat more difficult to supervise. There are firewall logs, of course, but those would have to be periodically scanned and searched for suspicious destinations (the "What customer is this?" question). A connection that is open "all day, every day" might turn up on a SIEM report as something worth investigating.
scuttlebutt P2P. new one for me.
( ran across it on a forum talking about moving a DHT crawler source repository off github and onto a scuttlebutt hosted git.. as the founders are banned or something )
2023-08-04 23:32 from zelgomer
Let's say, hypothetically, someone was such a workoholic that they
wanted to connect to their office PC from their home PC so that they
can work late nights and weekends. This person really prefers to use
their home PC because it's really good and has a nice big screen and so
on. Also it's super inconvenient to use the company laptop because it's
slow, the VPN requires frequent reauthentication, and security policies
and spyware has gotten so draconian that this person frankly doesn't
trust having the device in their home.
So this person devises a back door using ssh tunnelling over stunnel
(required to diguise the traffic as https because the company's
firewall won't allow ssh to make it out of the office). Which of these
two configurations do you think is the least suspicious or likely to
result in discovery?
1. Configure the office PC to open a stunnel client to a controlled
host, then use ssh over that to forward a remote port to localhost.
2. Configure the laptop to open a stunnel client to a controlled host,
then use ssh to forward that to the office PC. The laptop is Windows.
The laptop is then kept someplace isolated and connected only by
sequestered guest wifi when in use. When not in use, it's shut off and
put in a shed outside.>connection that has constant activity and never dies. 2 is more
My thoughts: 1 is simpler and more direct, but it looks like an https
wasteful since all data comes into the home network and then out again
through the vpn, but it has the benefit that traffic does go through
the vpn not wrapped in stunnel, so it looks the same as if a person
were just using the laptop normally, except for the active https
connection, but at least that comes and goes with the work hours, so it
looks like a human and not like malware.
I am the workaholic.
I also happen to be the chief sysadmin so I have an VPN link that joins a network segment in my house with office.
I dare say most offices that support people working remotely have some VPN access already set up. Ask your friendly sysadmin for your entry key.
If your firm won't let you get legit remote access you should not bother. RULE #1 of the employee is to never bother with something more than what your coworkers and direct upper-ups do.
That said:
I'd use Wireguard (UDP) to a controlled host using a well known access port (such as the UDP DNS port), since Wireguard is not a chatty protocol and won't generate traffic if you are not using it. THen you can Wireguard or ssh forward to the controlled host. The caveheat is your office sysadmin might be a motherfucker who smells like a horse who has DNS ports under interception or inspection and that would raise alarms.
Stunneling to an https port makes sense for short lived tunnels, since it will look like an https query unless looked at closely. Then again, your sysadmin might be a horse smelling motherfucker who has https traffic under inspection or interception and you are screwed again.
2023-08-07 10:07 from IGnatius T Foobar
I would do all of the following:
1. Block all outbound DNS lookups, except through the corporate DNS
Don't forget to force every DNS query not addressed to the corporate DNS into the corporate DNS server anyway via MITM. I do this a lot with office IoT devices that use hardcoded DNS servers.
ultimately, unless your IT/Security staff are morons or just dont care, that is the eventual outcome.
Tue Aug 08 2023 02:16:28 PM EDT from darknetuseryou are screwed again.
Punycode URL fake address. Learned something new today.
it looks legit, browsers even tell you the address you think it is, but Unicode underneath it points somewhere else. ( always malicious )
Well back to my next cloud being flooded to the point i cant use it. 100s this evening, one bad login attempt right after another. I guess i have to put a 2nd login in front of it on the proxy. Blows me using native apps with it unless i vpn in ( or am on the wire here, but sort of defeats the purpose ), but at least i can access the web client.
Frustrating.
2023-11-22 18:48 from Nurb432
Well back to my next cloud being flooded to the point i cant use it.
100s this evening, one bad login attempt right after another. I guess
i have to put a 2nd login in front of it on the proxy. Blows me using
native apps with it unless i vpn in ( or am on the wire here, but
sort of defeats the purpose ), but at least i can access the web
client.
Frustrating.
I have a firewall for that.
When a network application in any of my LANs detect some bruteforce, a syslog entry is submitted and then the offending address is added to a blacklist*. Then the IP is added to the firewall list of connections to kill.
* I use blacklists instead of blocklists or deny lists because black gatekeepers are just better than puny wokes. That is the reason why the fencer guarding the entrance to the cool night clubs is always a big badass black.
nginx is acting like a firewall, since i put logins on it ( but that of course kills native apps.. they cant do the double hop ). But not yet looked into if i can do block lists on its own. But the problem is that these IPs hitting me rotate, every 10th or so it changes, so my NC instance still gets hit too many times by the proxy, even if they were to get auto blocked at the proxy.
2023-11-23 12:10 from Nurb432
nginx is acting like a firewall, since i put logins on it ( but that
of course kills native apps.. they cant do the double hop ). But
not yet looked into if i can do block lists on its own. But the
problem is that these IPs hitting me rotate, every 10th or so it
changes, so my NC instance still gets hit too many times by the
proxy, even if they were to get auto blocked at the proxy.
Maybe consider switching to a reverse proxy that can work transparently?
I am using a bunch of relayds as TLS accelerators. They serve as TLS endpoints. They take care of TLS certificates and renewals and also add HTTP headers to the connections that hit the app servers so the apps know they are behind a reverse proxy.
Since the apps know they are behind a reverse proxy and are given the IP address of the actual client that is initiating the connection beyond relayd, they can dentify abusers by IP. If that makes any sense to you.
Ah, and since the setup is transparent to the client then there is no breakage with non-web apps.
I assume that NGINX native could, but im using an 'easy manage' version, unsure if it will do it, but i will look tonight.. But that said, having the little extra in between, makes me feel a little safer. Its just frustrating i have extra hoops to jump thru due to ass-hats. NGINX is taking care of the name routing for me, not just the SSL.
If i stick with web only, the double hop keeps me safe. and lets me continue to use things. I am going to look into adding fail2ban or something to it however. Wont solve the problem but woudl help with the load the flood imposes.
Of course going 100% vpn fixes it too. But back to the 'extra hoop'. And i lose the ability to publish to 'friends'. ( like pictures, chat )
Thu Nov 23 2023 12:17:56 EST from darknetuser
Maybe consider switching to a reverse proxy that can work transparently?
I am using a bunch of relayds as TLS accelerators. They serve as TLS endpoints. They take care of TLS certificates and renewals and also add HTTP headers to the connections that hit the app servers so the apps know they are behind a reverse proxy.
Since the apps know they are behind a reverse proxy and are given the IP address of the actual client that is initiating the connection beyond relayd, they can dentify abusers by IP. If that makes any sense to you.
Ah, and since the setup is transparent to the client then there is no breakage with non-web apps.
2023-11-23 12:54 from Nurb432
I assume that NGINX native could, but im using an 'easy manage'
version, unsure if it will do it, but i will look tonight.. But
that said, having the little extra in between, makes me feel a little
safer. Its just frustrating i have extra hoops to jump thru due
to ass-hats. NGINX is taking care of the name routing for me, not
just the SSL.
If i stick with web only, the double hop keeps me safe. and lets me
continue to use things. I am going to look into adding fail2ban or
something to it however. Wont solve the problem but woudl help with
the load the flood imposes.chat )
Of course going 100% vpn fixes it too. But back to the 'extra
hoop'. And i lose the ability to publish to 'friends'. ( like
pictures,
If you think Internet sucks, wait until you need to deploy some crappy lame ecommerce app your boss tells you to, and then watch bots rape the live chat systems, the email contact forms and the registration forms. It is brutal. A trial run for one of these here with a basic captcha managed to get 200 bots register fake customers in 10 minutes or so.
Fail2ban has modules developed for use without reverse proxies, for the most part. Some applications have modules that support reverse proxies, but honestly, fail2ban is gonna need a lot of work in order to get adapted the proper way.
I have seen people use fail2ban by having the computer that is running fail2ban check the logs (served over NFS or syslog) and then ssh into the firewall to update the blacklists. No need to say this is serviceable but sucks cocks.
Ok, ill skip F2B then. I did have it running back when all i did was SSH in. it was effective then, but i do realize that was a pretty simple use case too. If i end up going 100% vpn, i might look back and see if it has a plugin for that but wont spend much time. VPN will work, just didnt want to go there and lose a few 'nice' things.
And for what its worth at my place, front end security is someone elses problem :) And i believe they mandate capcha. We also block non regional IP addresses ( not perfect i know, but gets rid of a lot of the bots ). But, the system i support, while is available on internet, is for our in-house network accounts only, mandated SSO/MFA so i dont have to f- with the outside world issues other than DoS, and again, not my team's problem.
Thu Nov 23 2023 18:48:45 EST from darknetuser
If you think Internet sucks, wait until you need to deploy some crappy lame ecommerce app your boss tells you to, and then watch bots rape the live chat systems, the email contact forms and the registration forms. It is brutal. A trial run for one of these here with a basic captcha managed to get 200 bots register fake customers in 10 minutes or so.
Fail2ban has modules developed for use without reverse proxies, for the most part. Some applications have modules that support reverse proxies, but honestly, fail2ban is gonna need a lot of work in order to get adapted the proper way.
I have seen people use fail2ban by having the computer that is running fail2ban check the logs (served over NFS or syslog) and then ssh into the firewall to update the blacklists. No need to say this is serviceable but sucks cocks.
TOR Question: Do the official entry points change every so often?
Reason i ask is i dont get on often, but did this morning just to get updates ( using the bundled Firefox thingie, not a service or anything, and all default settings ) and it refused to connect. Everything was timing out affording to the log. Wondering if my ISP was doing something, tried the snowflake bridge, again, timeout. Tried another bridge set ( obfs ) and it did connect, then updated..
Now it works without bridges.
I would have thought that as long as the project itself was alive, the main entry points would be stable?