I'm having an issue with an SSH tunnel and I understand it may be a permissions issue with my local ports, most probably 127.0.0.1:3308. However I've run my program as an administrator (sudo python3 myprogram.py) and I still have the same problem - but surely the administrator should have access to everything? I've tried searching on here and Googling "permission on local ports" but I didn't find anything useful.
Context: I'm still trying to complete step 2 of my original request. I didn't get very far with my original question so I asked again on Github which is where I got the feedback about the permissions issue.
I'm also not sure what tags to put on this question - feel free to improve them. For me, this is Python 3 on a Raspberry Pi but if it's an issue with permissions then it's probably not specific to Python and it's likely to be Linux generally rather than Raspian specifically!
Thanks in advance.
So in this end, this wasn't an issue with permissions on ports (which is maybe why the question was downvoted) so I'm closing this question. I'll put the solution on the original question.
Related
Long story short, I was mounting a disk to my vm instances but I didn't specify the NOFAIL_OPTION on /etc/fstab. Thus, after resarting the instance, i could not access the ssh. After trying to access the serial console, I got the error in the image above. I have tried to search some answer and have add startup script to add sudo user
However, it didn't solve my problem. Basically,I need the data on the boot and additional persistent disk. Would appreciate any help. Thank you.
I solve the problem by making changes to the file by attaching the bootable disk as additional disk on new instance just like John said in his article
:) Thanks! hope this will be helpful for those who could not access ssh and need to make changes to the unbootable system file.
This also happened to me recently. I solved the issue by attaching the boot disk of the problematic instance to a new instance, however, the NO_FAIL causing the system to break is what interests me. This has never happened before. The UUID is correct, and the syntax is also correct, hence what was the cause of the original problem in your case? I'm still trying to figure mine out.
We have a virtual webserver with ubuntu 12.04. Today we recived a message form the webhoster, because there are illegaly activities on this server.
I found bad code on different joomla installations and cleaned it. Now i have two proccess on this server, startet form our ftp-user with the following commands:
/tmp/ntp.client -p9406 -d
/tmp/smartctl.dump -p3218 -d
they used a lot cpu time and are similar and google says nothing to ntp.client or smartctl.dump
Can anybody say somthing about this processes. Can I kill them?
Thanks
PS: sorry for my english!
Unless you installed it to /tmp yourself, get rid of it. And reinstall the server. Those two are easy to spot. You have no idea how many well hidden backdoors you already have on the system. Or better yet - get someone to install it for you and take care of it/secure it for you ...
edit: And see this canonical question and the other linked questions on ServerFault, where this question actually belongs.
I would like to start out by apologizing. I have very little knowledge in the areas of Linux and Servers. I have been asked at work to set up a Linux box running Apache Tomcat. The Server needs to be enabled to allow websockets. I managed to get Debian installed. During the installation it gave me the option to make it a web server, which I did. There are now some different folders and files that are named "apache" in the files system, so my guess is that I am in fact running Apache, but to be honest I'm not 100% sure, and if it is, I don't know if its Tomcat. I fumbled around a bit and figured out the IP address of the computer I installed on and tried going to that IP from another computer in the network and it worked. I was able to see the html file that I put in the /var/www folder on the host machine. I then went out and found a nice piece of code, someone was kind enough to share, that is suppose to test websockets capability but I cant seem to get it working. My thinking is that my server isn't allowing PHP to run. I came to this conclusion by testing. I took a web page from my other server, its written in PHP, that when opened will send a text to my phone. Its just a small piece of code that I used for testing. When I tried running it from the Linux server it wont run, meaning it wont send the text to my phone. So here I am. I realize I'm asking for a simple solution to a complex problem, but I'm under the gun so to speak. I have about a week to get this going, so I just don't have the time to really immerse my self in this stuff the way I would like to. My question in its simplest form is"How do I configure my server to run PHP?" Any help/advice would be greatly appreciated! Thank you all for your time and patience.
Have you tried running a simple PHP script like echo 'Hello World';??
If not then try, if it works then your PHP is up, but sockets are just not configured to use.
If it doesn't work then install Ubuntu, a simple newbie friendly interface for Linux, and then install LAMP, here its how to do it.
And don't panic.
Is there a way to execute commands using directory traversal attacks?
For instance, I access a server's etc/passwd file like this
http://server.com/..%01/..%01/..%01//etc/passwd
Is there a way to run a command instead? Like...
http://server.com/..%01/..%01/..%01//ls
..... and get an output?
To be clear here, I've found the vuln in our company's server. I'm looking to raise the risk level (or bonus points for me) by proving that it may give an attacker complete access to the system
Chroot on Linux is easily breakable (unlike FreeBSD). Better solution is to switch on SELinux and run Apache in SELinux sandbox:
run_init /etc/init.d/httpd restart
Make sure you have mod_security installed and properly configured.
If you are able to view /etc/passwd as a result of the document root or access to Directory not correctly configured on the server, then the presence of this vulnerability does not automatically mean you can execute commands of your choice.
On the other hand if you are able view entries from /etc/passwd as a result of the web application using user input (filename) in calls such as popen, exec, system, shell_exec, or variants without adequate sanitization, then you may be able to execute arbitrary commands.
Unless the web server is utterly hideously programmed by someone with no idea what they're doing, trying to access ls using that (assuming it even works) would result in you seeing the contents of the ls binary, and nothing else.
Which is probably not very useful.
Yes it is possible (the first question) if the application is really really bad (in terms of security).
http://www.owasp.org/index.php/Top_10_2007-Malicious_File_Execution
Edit#2: I have edited out my comments as they were deemed sarcastic and blunt. Ok now as more information came from gAMBOOKa about this, Apache with Fedora - which you should have put into the question - I would suggest:
Post to Apache forum, highlighting you're running latest version of Apache and running on Fedora and submit the exploit to them.
Post to Fedora's forum, again, highlighting you're running the latest version of Apache and submit the exploit to them.
It should be noted, include the httpd.conf to both of the sites when posting to their forums.
To minimize access to passwd files, look into running Apache in a sandbox/chrooted environment where any other files such as passwd are not visible outside of the sandbox/chrooted environment...have you a spare box lying around to experiment with it or even better use VMWARE to simulate the identical environment you are using for the Apache/Fedora - try get it to be IDENTICAL environment, and make the httpd server run within VMWare, and remotely access the Virtual machine to check if the exploit is still visible. Then chroot/sandbox it and re-run the exploit again...
Document the step-by-step to reproduce it and include a recommendation until a fix is found, meanwhile if there is minimal impact to the webserver running in sandbox/chrooted environment - push them to do so...
Hope this helps,
Best regards,
Tom.
If you already can view etc/passwd then the server must be poorly configured...
if you really want to execute commands then you need to know the php script running in the server whether there is any system() command so that you can pass commands through the url..
eg: url?command=ls
try to view the .htaccess files....it may do the trick..
How come I always get
"GConf Error: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://projects.gnome.org/gconf/ for information. (Details - 1: Failed to get connection to session: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.)"
when I start 'gedit' from a shell from my superuser account?
I've been using GUI apps as a logged-in user and as a secondary user for 15+ years on various UNIX machines. There's plenty of good reasons to do so (remote shell, testing of configuration files, running multiple sessions of programs that only allow one instance per user, etc).
There's a bug at launchpad that explains how to eliminate this message by setting the following environment variable.
export DBUS_SESSION_BUS_ADDRESS=""
The technical answer is that gedit is a Gtk+/Gnome program, and expects to find a current gconf session for its configuration. But running it as a separate user who isn't logged in on the desktop, you don't find it. So it spits out a warning, telling you. The failure should be benign though, and the editor will still run.
The real answer is: don't do that. You don't want to be running GUI apps as anything but the logged-in user, in general. And you never want to be running any GUI app as root, ever.
For some (RHEL, CentOS) you may need to install the dbus-x11 package ...
sudo yum install dbus-x11
Additional details here.
Setting and exporting DBUS_SESSION_BUS_ADDRESS to "" fixed the problem for me. I only had to do this once and the problem was permanently solved. However, if you have a problem with your umask setting, as I did, then the GUI applications you are trying to run may not be able to properly create the directories and files they need to function correctly.
I suggest creating (or, have created) a new user account solely for test purposes. Then you can see if you still have the problem when logged in to the new user account.
I ran into this issue myself on several different servers. It I tried all of the suggestions listed here: made sure ~/.dbus had proper ownership, service messagbus restart, etc.
I turns out that my ~/.dbus was mode 755 and the problem went away when I changed the mode to 700. I found this when comparing known working servers with servers showing this error.
I understand there are several different answers to this problem, as I have been trying to solve this for 3 days.
The one that worked for me was to
rm -r .gconf
rm -r .gconfd
in my home directory. Hope this helps somebody.