Tzomb1e

So I agree with Eigenvektor, but wanted to add one extra note. While not the most likely scenario depending on the manufacturer, using an SFP port as an extra RJ45 interface can add an additional point of failure (bad module). As long as you get quality hardware, this probably is not going to be an issue. It is always worth keeping in mind just in case you need to troubleshoot any kind of connection issue off of that interface.

It may be worth checking other computers/devices in your network to make sure there is not another infected host that is spreading the trojan/miner. Assuming you did not go to a malicious site (or in the unlikely event that cloudflare redirected you to a malicious website with a poisoned record), depending on the malware it can spread to different hosts on your LAN. It may be that the origin point of infection is on another computer. I supposed there is also the possibility that you could have picked up the trojan prior to you detection and its payload was time based...that is also a bit unlikely for the situation but you never know! Do you know the name of the trojan/miner that was detected? It should be in the logs on Malwarebytes. Malwarebytes labs normally has pretty detailed write ups for what the malware does and how it spreads. Are you sure it was not a false positive?

Very good! I am glad you got it working. I have never tried to use a wireless interface with pfSense, so good to know that it actually works!

So there are quite a few considerations to make with the setup for it to work as intended. The short answer to your question is no, you cannot setup the same interface as the WAN and LAN on a pfSense. The long answer is potentially. You can create rules for either interface of course, so if there is a way to enable hairpinning you could potentially create a WAN rule to allow the filtering and routing of traffic on the same interface. I have never looked for this option in pfSense, so it may make for an interesting exercise down the road. As a precursor, my apologies if I repeat anything you already know or have done. I like to go through the steps to make sure nothing is missed ?. To make it work, you will need to create two bridged network interfaces for the pfSense VM in VirtualBox with separate MAC addresses. This will give your guest psSense its LAN and WAN interfaces so your rules can be applied to one side or the other. You will also need to statically assign different IPs to either interface since your pfSense will be the DHCP server for your LAN and the WAN interface will not be able to pull an IP from another DHCP server. Since the IPs are being set statically, your pfSense box will not have any dynamic routes to know where to forward traffic, meaning you will need to also configure a default static route towards your ISP router across your WAN interface (along with making sure NAT is applied to the outbound traffic so the router sends return connections to the correct interface). This will allow the pfSense to take traffic, know where to forward traffic, and allow the rules to be applied. Then, configure your DHCP server on the pfSense and verify that it is disabled on all other devices in the LAN. One other consideration is how your DNS is setup. If you are using the pfSense, make sure that the LAN interface address is set in your DHCP options and you have either the DNS resolver or forwarder enabled along with upstream servers for recursive lookups. If you want the ISP router to be your DNS, just make sure you have it configured in your DHCP options. Personally, I would let the pfSense handle this so everything is going through one place. TLDR: - Static IPs on LAN and WAN interfaces (bridged in Vbox with different MACs) - Static default route for forwarding traffic to the ISP router - NAT on outbound traffic (should be enabled by default if I am not mistaken) - Rules for filtering traffic - Enable DHCP on the pfSense and disable in all other devices - DNS setup in DHCP options Typically I use pfSense in Vbox to control a sandbox/lab, so one interface on the internal network with my other guest vms and the other bridged. I have never really attempted what we are trying to accomplish here. If I have some time this afternoon, I will try and set everything up like you have and verify I am not missing any steps. Anyone reading this, feel free to correct me if I am mistaken or missing something! It is still early so my brain may not be working at 100 % ? Edit: I forgot to answer your other question about the WAN interface. My bad! In your setup, the WAN and LAN titles are more for direction of traffic rather then what is on either side. Traditionally, yes, the WAN interface is the Internet side with the LAN being the local side. That is still somewhat true here since traffic going out the WAN interface will almost certainly be Internet bound, though its next hop is the ISP router. Small detail, but worth mentioning.

To me it seems that the DC is not registering itself properly with the DNS server, hence why the record has "DC1.lan" instead of "DC1.ecorp.local" when you do a lookup by IP.

I may have missed something in the replies, but do you have your DHCP server assigning the DNS suffix for your domain and do you have it added to your DC? Based on the results below, the FQDN for the DC is still using .local and your DNS is only checking .local.

I will at least add my two cents on this. I may ramble a bit, so forgive me for that or any mistakes. Based on the VirtualBox documentation and a forum conversation, guest OSes see wireless adapters as a wired connection and cannot be seen as a wireless adapter due to how VBox creates the bridge (we have already discovered that, of course). While the guest OS sees the interface as being wired, communications between your guest and your LAN should still work properly. If you absolutely need the interface on your pfSense to show as wireless you must attach a USB wireless adapter and pass it through to the guest (as you have done) and configure the device on the guest. That also means making sure that the adapters you are attempting are supported. See the netgate link below for their supported wireless card documentation. I also have links to Oracle's documentation on bridged networking and freeBSDs official page on configuring wireless below just as a reference. https://docs.oracle.com/cd/E97728_01/E97727/html/network_bridged.html https://www.freebsd.org/doc/handbook/network-wireless.html https://docs.netgate.com/pfsense/en/latest/wireless/supported-wireless-cards.html Personally, I think you should skip trying to make your laptop an AP. USB wireless adapters are not really meant to act as the AP in that relationship and, while they sometimes can work in this function, typically do not give the greatest performance (at least from my experience). With your setup (unless you decide to add another AP), I would probably use the ISP router as your AP and have your DHCP set to use the LAN side interface of the pfSense VM as the default gateway. This would force DHCP clients to send traffic to the pfSense that is meant for outside of your LAN and subject to your firewall rules. You may have to play with the routing on the pfSense as well so it forwards traffic properly. Since it is not inline, anyone could simply set their IP address statically and bypass this. If the ISP router has the capability to do so, you could prevent this with ACLs and NAT on the pfSense. Its a messy solution, of course. Again, just my two cents. Feel free to ignore me. ?

You got it! ?

You need to setup separate networks in Virtual Network Editor that point to either adapter (Edit>Virtual Network Editor...). Once these are setup, you can attach virtual adapters to these on the VM itself. Here is a link to the networking documentation of VMWare Workstation Pro 15. You can get the same documentation for lower versions as well. https://docs.vmware.com/en/VMware-Workstation-Pro/15.0/com.vmware.ws.using.doc/GUID-AC956B17-30BA-45F7-9A39-DCCB96B0A713.html

My question is more out of curiosity...is it normal for people to walk around with music playing out of their closed laptops? I am not sure I have ever seen that...sitting and working on the laptop and letting music play, sure, but never carrying it around like a boombox! I know not everyone can afford bluetooth headsets, high end smart phones, or whatever else...I just thought I would ask! No judgement, just curiosity. Also, go with the SSD...not only will it be mostly unaffected by movement, but it will also speed things up for you.

Investigations of any kind are normally my favorite part of the job, they tend to get passed a little further down the chain anymore however. This is the first one I have been able to take on myself in a while due to copious other projects. And that is more or less all it is: a windows device making noise that got my attention. Our field support team just acquired three greenies right out of school, I have already had my normal "this network is not your playground" talk and specifically asked them about this traffic but I do have my doubts. Fortunately I have some surprise posture assessments in their territories next week that will let me validate their stories, so we will see how things hold up.

The forwarding interface does not have any virtual interfaces. The ingress interface does, though. Unfortunately I cannot share any of the logs. While they do not contain much other than the packet information that I am pulling from my sinkhole, which only has IP, MAC, and information from the DNS query, I am not allowed to share them. Sorry!

I have the IPs, but the only MAC is from the forwarding gateway...which is the forwarding interface of our core router :D. Since it appears to be in a different broadcast domain, I lose the original MAC the second it is forwarded to another LAN segment. The traffic, at least from what the IDS/IPS, firewall, and my sinkhole has caught, has only been DNS queries that are not registering the device name with our DHCP. So the only information the logs give me is the RFC1918 address of the device and the site it is trying to resolve (which has all been normal windows traffic for Microsoft time and NSCI servers). The IP is almost useless since the subnet it is using does not exist in my environment.

I have considered this, but the corporate policies are somewhat lax on what can be used on the network which makes this way too tricky for me to truly consider. Some of the scope options, like lease, I have already worked on. The devices in question were detected by our IPS/IDS and I have been monitoring their traffic across our edge firewall. While I can just block them logically, finding them physically would be best. With my lack of resources, I may just have to settle for the former...but one can dream!

I did not consider a script, for some silly reason. I will work on that. Thanks! I have been trying to convince those that make choices to allow my team to push forward with 802.1x or ISE or really any NAC...but all they see is cost...and, like you said, the administrative overhead would lead to a larger headcount. Thankfully we do use the same vendor for our infrastructure equipment. They have not been properly cared for, however, and centralized management/logging has been hit or miss during setups.

Thank you for the recommendations! That is one of the options I have been debating...since I cannot pin down the exact location that the traffic is coming from, it would involve more than 100 switches :D. I realize I am a bit limited on my options to begin with, but I just wanted to make sure I was not missing something simple. I appreciate the reply!

I apologize if this belongs in another section...due to the issues, networking seemed most appropriate. I am currently searching for a couple unknown hosts on a network that consists of more than 60 subnets with almost as many physical locations. All remote locations connect back to the core with MPLS. Normally, I can follow the L3 or L2 information back through the infrastructure to discover the source. However, the hosts in question are using a network that does not exist within the architecture and can only be seen sending traffic to addresses that are very similar to my DNS servers. By similar, I mean they share the same last two octets, but not the first two. I was able to create routes to direct the DNS traffic towards a sink hole in order to capture the packets and see the contents of the requests...but this only yielded queries for windows time servers, NCSI servers, and other windows based system services without any host information. Since there is no preexisting network route (static or shared), there is no trail to follow back to the host. Any L2 information in the captured packets only show the MAC from the forwarding gateway, as expected from L2 logic. Unless my brain is misfiring, the host would have to be configured with a gateway that falls within it's IP subnet (especially for a windows host) in order to properly forward any non-lan requests to external networks. Since the network is not one that "exists" in the architecture, this leads to a bit of assumption that another router would have to be in place (not using NAT unless dynamic is being used since I have two different source addresses) in order for the hosts to send the traffic to its gateway, which can then send the traffic into my other networks assuming next hop information has been added (or the routing device is pulling a DHCP lease). Creating SPAN ports on the core infrastructure devices is not a possibility due to even the slightest risk of network degradation. A tap is possible, but I think I would end up with the same information from my pseudo honeypot/sinkhole. Anyone have any advice that would save me from touching every device at all 60 locations? I am going to dig through the leases to see if any hostnames might stand out, but this is still tedious. While I realize there are a million technologies for asset management that would assist with this, the company in question has never really cared about proper infrastructure maintenance and monitoring...which is why this is being done by hand.

Hail Hydra...

One of the benefits of them releasing this open-source is the ability of the community to find holes and security flaws with the design. There has already been an issue discovered when Ghidra is run in debug mode. When debug mode is enabled, Ghidra by default listens on all interfaces using port 18001. The flaw is easily fixed by changing one line of code.

In all honesty, I am just curious what you are trying to achieve with this. As Mariushm said, I would just snag a couple nice ethernet or fiber cards for you computers and connect them with proper ethernet or fiber cabling.

If it will function without a connection to their Cloud APIs, I would almost just toss a pfSense box in with a rule dropping traffic from those devices trying to leave the LAN. I know you said you have to use the ISP provided router/gateway, but you can have your LAN devices use the pfSense box as their primary gateway and then have the pfSense forward all WAN traffic to your ISP's router/gateway. This would allow the devices to communicate with you LAN without needing extra VLANs, and allow you to control what devices have WAN access. You can go the ACL route as well, I would just be concerned if the devices need to communicate back and forth from a LAN perspective. You could still have the LAN traffic with the ACL, you would just have to make sure you configure the layers of the ACL properly to permit traffic leaving the segmented VLAN only if the destination IP is still on your LAN.

It is difficult to say for certain whether that would fix your issues or not. There are many factors with wireless performance (signal strength, band, interference, load, router/AP throughput, USB adapter throughput, etc, etc). However...any modern ethernet cable and router/switch should be able to provide you MUCH better throughput than 81kb/s. You also have to consider the type of service you are being provided from your ISP as well as what other traffic may be bottlenecking your connection. Your internal devices and connections cannot help your transfer speeds from outside of your network.

Ultimately, subnetting would have been beneficial here. Instead of 192.168.0.0/24 and 10.0.0.0/24, it would have been cleaner to use something like 192.168.0.0/25, 192.168.0.128/25 depending on the amount of hosts needed anyway. If you need a full class C for each floor, then 192.168.0.0/24 and 192.168.1.0/24. You can still use your current addressing of course...it is just messy :D. Assuming the VLANs are already present, all you should need is a static route on the primary router telling it where to send the traffic.

Are both the modem/router combo and the Linksys router configured to handle DHCP and DNS requests? Having two "servers" handling these requests can cause issues with hosts trying to acquire new IP leases and also in attempting to resolve server names. I would decide which device you want to be the default gateway for your environment and disable those functions on the other if you have not already done so.

Sorry for the delay. I personally use the TP-Link AV2000. My only complaint is how bulky they are, but with the performance I get out of them, that complaint is minimal. They are a little pricey, I got them during a black friday sale last year sometime for less than they are now. https://www.amazon.com/TP-Link-Powerline-Pass-Through-TL-PA9020P-KIT/dp/B01H74VKZU/ref=sr_1_3?ie=UTF8&qid=1543506670&sr=8-3&keywords=tp-link+av2000 Also good to keep in mind. YMMV since there are so many factors with powerline. I purchased mine knowing that under best case scenario it could handle the throughput I was wanting plus a fair percent more.