Is there a (simple) way to have puppet use a file available on the internet for the Source property of a File?
eg:
file { "/home/text.txt":
source => [
"http://www.example.com/text.txt",
]
}
I provide a server (and site) to a client via Rackspace Cloud Hosting, and my client wants to now host the entire thing within his own account.
Since it's not possible to just transfer the ownership, I need to somehow create an image of the machine via SSH which I can then use on a new server.
Is this possible, and does anyone know of a way of doing this.
Note
I am talking about virtualised machines here, but I only have access to the virtualised partition and not the system as a whole.
I have setup squid proxy on an ubuntu server with DB authentication. However, whilst connected to the proxy, if I visit http://www.whatismyip.com/ it still shows my ACTUAL ip address. How can I configure Squid to hide my IP and to hide the fact it's using squid.
I'm running a server which currently has about 50 sites on, and am encountering from problems with IIS.
Everytime I try and change a setting on a site, switch .Net versions, add/change domains on a site directly in IIS Manager. IIS Manager crashes. When I start up the manager again, all the sites are down.
Does anyone have any advice on how to fix this, without having sites down for a significant period of time?
Thanks in advance,
I need to setup Squid Proxy and OpenVPN up on the same server, using the same Radius authentication source for both.
Both will be accessable from different ports, but my question is. Is this possible, or are there any overlaps that may stop it working?
This is a Canonical Question about Server Security - Responding to Breach Events (Hacking)
See Also:
Canonical Version
I suspect that one or more of my servers is compromised by a hacker, virus, or other mechanism:
- What are my first steps? When I arrive on site should I disconnect the server, preserve "evidence", are there other initial considerations?
- How do I go about getting services back online?
- How do I prevent the same thing from happening immediately again?
- Are there best practices or methodologies for learning from this incident?
- If I wanted to put a Incident Response Plan together, where would I start? Should this be part of my Disaster Recovery or Business Continuity Planning?
Original Version
2011.01.02 - I'm on my way into work at 9.30 p.m. on a Sunday because our server has been compromised somehow and was resulting in a DOS attack on our provider. The servers access to the Internet has been shut down which means over 5-600 of our clients sites are now down. Now this could be an FTP hack, or some weakness in code somewhere. I'm not sure till I get there.
How can I track this down quickly? We're in for a whole lot of litigation if I don't get the server back up ASAP. Any help is appreciated. We are running Open SUSE 11.0.
2011.01.03 - Thanks to everyone for your help. Luckily I WASN'T the only person responsible for this server, just the nearest. We managed to resolve this problem, although it may not apply to many others in a different situation. I'll detail what we did.
We unplugged the server from the net. It was performing (attempting to perform) a Denial Of Service attack on another server in Indonesia, and the guilty party was also based there.
We firstly tried to identify where on the server this was coming from, considering we have over 500 sites on the server, we expected to be moonlighting for some time. However, with SSH access still, we ran a command to find all files edited or created in the time the attacks started. Luckily, the offending file was created over the winter holidays which meant that not many other files were created on the server at that time.
We were then able to identify the offending file which was inside the uploaded images folder within a ZenCart website.
After a short cigarette break we concluded that, due to the files location, it must have been uploaded via a file upload facility that was inadequetly secured. After some googling, we found that there was a security vulnerability that allowed files to be uploaded, within the ZenCart admin panel, for a picture for a record company. (The section that it never really even used), posting this form just uploaded any file, it did not check the extension of the file, and didn't even check to see if the user was logged in.
This meant that any files could be uploaded, including a PHP file for the attack. We secured the vulnerability with ZenCart on the infected site, and removed the offending files.
The job was done, and I was home for 2 a.m.
The Moral - Always apply security patches for ZenCart, or any other CMS system for that matter. As when security updates are released, the whole world is made aware of the vulnerability. - Always do backups, and backup your backups. - Employ or arrange for someone that will be there in times like these. To prevent anyone from relying on a panicy post on Server Fault.