VirusTotal and Verified Signature are both OK. Checked running processes - All system processes check out using Process Explorer.Malwarebytes & Root kit - Nothing detected.Anti-Virus scan - We use Trend Worry Free and it hasn't detected anything odd coming from or two the server.Something is definitely going on in my environment, but so far the normal steps to rectify the situation have not yielded any results. I have looked up the error code (sorry, can't remember what it was) and it is most commonly associated with a computer virus. Auto-updates started to fail - Our monthly patching is starting to fail on most of the servers that are sending the traffic.The requests appear to be coming from the OS and not any rogue application. Wireshark is detecting the traffic as a DNS request for certain A records.I have added a block rule to all traffic to Russia, but that doesn't solve the issue The IP address changes, but it always seems to be the same group of addresses. SonicWALL is detecting traffic to/from multiple servers to/from Russia.VMWare CPU utilization has increased dramatically and without any major changes on the server.I then looked at each of the servers more closely and I have noticed some things that all point to an infection of some kind. We have multiple servers that are trying to send data to Russia. While going through my monthly review of all traffic I came across some extremely suspicious activity in my logs that I just can't figure out. ![]() All servers running Server 2008R2 and are patched using WSUS.VMware 5.5 with 3 hosts and a back-end SAN - All Dell.Would be great if the Rescue disk could be amended to include virtio_blk.ko (VirtIO block device) and virtio_pci.ko (needed by the newer virtio_scsi.ko (VirtIO SCSI block device) driver which itself is already included).First a little information about our environment | cpio -H newc -o | xz -check=crc32 -x86 -lzma2 > /tmp/initrd.xz Ĭp -a /lib/modules/4.9.57-$f/kernel/drivers/block/virtio_blk.ko block Ĭp -a /lib/modules/4.9.57-$f/kernel/drivers/block/cciss.ko block Ĭp -a /lib/modules/4.9.57-$f/kernel/drivers/scsi. Xz -d -c -k /livemnt/boot/boot/grub/initrd.xz | cpio -i Ĭd /tmp/initrd/lib/modules/4.9.57-$f/kernel/drivers Ĭp -a /lib/modules/4.9.57-$f/kernel/drivers/virtio. This was perfect, managed to rebuild the initrd.xz file to include additional drivers by booting a VM using the ISO and then replacing the initrd.xz file on our TFTP server with the /tmp/initrd.xz file. I can make all virtio drivers builtin in next KRD patch. ![]() Initrd %some path%/krd/boot/grub/initrd1.xz If it’s additional initrd then you’ll need to add it into kernel boot parameters:įor pxelinux/syslinux: INITRD %some path%/krd/boot/grub/initrd.xz,%some path%/krd/boot/grub/initrd1.xzįor grub: initrd %some path%/krd/boot/grub/initrd.xz %some path%/krd/boot/grub/initrd1.xzįor iPXE: initrd %some path%/krd/boot/grub/initrd.xz Now you can use /tmp/initrd1.xz for loading KRD. | cpio -H newc -o | xz -check=crc32 -x86 -lzma2 >. initrd.xz | cpio -iĢ. Copy drivers into /tmp/initrd/lib/modules/%kernel%/kernel folderģ. Create new initrd: find. Copy current initrd.xz into /tmp (only for rebuilding) and run following command in terminal as root: cd /tmpįor rebuilding extract existing initrd: xz -d -c -k. ![]() Step are similar (use only Linux, on Windows result archive will be broken):ġ. You can rebuild or create new additional initrd file (kernel will merge all initrd files into one filesystem). Hi, do I check and rebuild the initrd image to include additional drivers?
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |