Long story short, our company's passowords got leaked, which led to many successfull logins to our sites, FTP servers, cloud accounts, etc. Causing many data loss, plenty of time to recover it and prevent it from happening from the future.
It is our fault, we stored our passwords in a file, which was located on our cloud, but the one who did it must be someone who might have access to that cloud, possibly someone who worked in the company in the past.
I installed a plugin to one of our WordPress sites to see the login attempts. I can see the IP of a person who tried to login with the correct password (however, we changed it already). When I tried to look up some info about the IP able, it was an IP of a TOR browser. I am new to this, but AFAIK it is practically untraceable.
My question is, is there a way (easy or hard) to trace this attacker?
Practically, no.
Tor is designed to obfuscate the origin of a connection. In order to break Tor's anonymity, you'd have to see the traffic entering and leaving the Tor network. With some clever correlating you could then find out who's connecting where (the NSA & co are doing that) but for a normal person/company this is impossible.
Related
I recently set up a subdomain on my website with the intention to soon clone my website for testing purposes. Subdomain was "beta", so beta.example.com
It was set up and password protected via htaccess and is directed through Cloudflare, it's about three days old and was never announced publicly (only I know of it).
Today I notice this on my Apache Server Stats page:
Also, CPU load was increasing and very, very high. Upon refreshing, this continued and is actually still continuing right now. Is this some sort of botting/brute force attack? I can't imagine how/why else so many IPs would be accessing this unlinked/private subdomain. I've since taken it down from Cloudflare DNS and the IPs are still connecting somehow, I assume it will take time for it to propagate.
Is this malicious? And how can it be prevented? I assume it was/is attempting to brute force the htaccess password? Is it because it's a common subdomain name? ("beta") - would it matter? Again, it's only been about three days so damn they work fast.
It can be search engine robots, It can be script kiddies, It can be brute force, you can have more information in your log file or by analyzing IP address.
I'm not sure to really understand your problem and what you want.
If you website is online, so yes some people/bots/robots will try to access to it, like any other website.
If you don't want than anybody access to your website, you can add an IP restriction.
I am not sure what this problem says. Please Help me to figure out this issue.. Thanks in Advance..
(403) Forbidden Issue
From the error text, it states "(403) Forbidden" is the issue. Fortunately for you, that particular issue is covered directly in the FAQs (https://chocolatey.org/install#faqs) of the install page, which links you over to Troubleshooting (https://chocolatey.org/docs/troubleshooting#im-getting-a-403-unauthorized-issue-attempting-to-install-chocolatey).
Details
For full answer clarity, linked information above will be provided here, but be sure to check the links above for the most correct and up to date answer.
It could be one of a few things:
You have a proxy that you need to configure
It is being blocked in your organization
We broke something (this is the least likely reason, everyone would be running into this issue and it would be fixed immediately)
CloudFlare has blocked your IP due to reasons
The Chocolatey Community Team may have blocked access due to abuse (many package installs over 30 days) see excessive use for details
You can use a tool like Fiddler (choco install for this would not be helpful in your case) to help determine what is going on.
How To Fix
Go to Project Honeypot and put in your IP address - http://www.projecthoneypot.org/search_ip.php. Check to see if your IP is flagged here, this is what Cloudflare uses to determine if you are banned (typically it means you have malware that is sending spam emails).
If you determine it is CloudFlare blocking your IP (which is the issue 98% of the time), we may be able to get you whitelisted for Chocolatey:
Go to https://chocolatey.org/contact (NOTE: If you are completely blocked from accessing the site, contact Chocolatey folks through Gitter instead)
Select "Website" in "Send message to" drop down
Let us know what's going on along with your IP address so we can unblock you.
Oh, and be sure to run some antivirus scans and remove any found malware (and maybe find a better antivirus scanner).
Once this has been completed, you should have access to install Chocolatey and/or packages from the community repository.
One case in FAQ is that the dl site being blocked by my organization, and it turns out to be true:
zscaler is being "helpful" again, and thinking nircmd is Trojan this time; last time it was Groovy that was blocked for me, sigh...
One of my clients just received the software ordered from his chosen developers, asked me to look at it and prepare the hosting procedures.
It's an Java (jar) app, so far so good ... but I saw something suspect, every 60 minutes or so the software connects to a remote host :443 port using SSL and transferring ~ 3-10 MB of encrypted data (as POST) then closes the connection, this is very strange. Tried to wireshark it but everything is encrypted and I have no clue about what kind of data is transferred, I know only the destination hostname. The hosted data within the app will be highly sensitive (insurance-broker) and if my client decides to go with it - this is a serious issue for his business and also for his clients, I've asked the developer company about this and they said that no one added something like this even if I provided them the proff (pcap).
I can block it within firewall, but if they added something like this it could exist another hosts ready to receive the encrypted data.
The only way I can figure it out is to somehow decrypt the SSL traffic in order to read RAW data and give my client all the needed informations in order to talk with the developer company to sort it out, how can I do that ? With some sort of ssl-proxy or whatever ... tried to google it but didn't find any kind of relevant tutorials.
I have access to the physical machine which is running the Java application, I can see every single bit of the traffic but ... encrypted.
If I was in your place instead of trying to decrypt ssl connection would have tried following steps:
1)Since you are aware of the host to which it is making a post request , find out more about that service so as to learn what it does ? May be try contacting that site saying that we need to consume your service what should I send my in post request ;)
2)Second way around would be if you can decompile the jar file and find line in the source code which makes that request and then you could go back to the developer asking as why this has been written. To find the source code which is making the call what you could do is block the host access on your firewall.
The code would fail and mostly probably he would have logged the exception in his log files. Find the stack trace and you will know the line of code that is
making that request.
Hope this helps.
I want to modify my application URL from //localhost:8080/monitor/index.html to just monitor , so that on putting monitor on browser, my application should open. Is there a way to achieve this, can someone suggest the configuration changes which will be required for this.
Can I map my short URL to the existing one may be somewhere in web.xml. I am not sure about the approach any suggestions will be great.
Thanks and regards
Deb
You're mixing up several different protocol layers in your question.
If you just enter nothing but "monitor" in the browser URL bar the browser is going to first lookup "monitor" in DNS and finding nothing it will then probably send a query to Google or your configured search engine. In the past browsers have taken other steps, such as appending ".com" and prepending "www." but I don't think modern browsers do that any more.
So far, your server is not even remotely involved.
If you're a large ISP user (TimeWarner, Comcast) and use their DNS it's also possible the ISP will intercept your failed DNS lookup and route the request to a "helpful" search page (i.e. SPAM) of their own.
At this point the request is still nowhere near your server.
I suppose you could mess with the /etc/hosts file on your local system to resolve "monitor" to the proper hostname, but that's an extremely brittle solution that has to be hard coded on each machine you want to have this "shortcut" link (and which breaks when the hostname changes).
You're much better off just setting up a web shortcut in your browser that points to the right place.
Hey guys, i've been googling ambitiously but my searches seem to be somewhat ambiguous so I thought i'd ask here.
My company has asked me to look into a web portal system that allows clients to log in via their browser and view/download their specific invoices / reports (the web server would be inhouse).
These (initially at least) would be static documents, pdf's, maybe excel spreadsheets and the like.
What I want to happen is a customer heads to our website (hosted elsewhere), clicks a link that takes them to a secure login for our webserver, they then enter their login details and are taken to their respective 'folder' on our webserver. Here they can download pdf's - that we keep up to date.
The main considerations are for it to be secure such that users can't access other users' folders and for users not to have to install anything to be view download their documents.
I'm setting up a pc to be a LAMP server right now, i've read WebDAV would be a good way to go but i'm not sure about how to get that working in a browser? Any advice or resources you guys can point me to give me a bit more direction would be greatly appreciated.
Thanks, Rob
If you've only got a handful of accounts to manage, apache's built-in HTTP Auth password stuff works pretty well; you write usernames and hashed passwords into an .htpasswd file with the htpasswd utility.
Then you use <Location> directives to specify the URL and directories to find the data, and inside the <Location> directives, use the Require directive to either list specific usernames or valid-user.
Just make sure your .htpasswd file isn't stored in the web root. You don't want people to get a hold of the thing and start brute-forcing your passwords (or see your other allowed users, in case client privacy is a priority).
But it is pretty heavy maintenance -- password changes pretty much have to go through a human. I imagine someone has scripts to automate that, but I wouldn't trust them very far. :)
If you want something that scales larger, I think you might be better off building such a tool yourself.