netcat does not work on glassfish - glassfish

Maybe a simple explanation for this but it seems that glassfish (on port 8080) does not respond normally to netcat requests ...
for example:
nc localhost 8080
OPTIONS
... nothing is 'returned' and netcat exits. If you do a similar thing against www.google.com 80 you will get an expected error message returned from the server.
Is glassfish setup to ignore netcat requests or something?
Reason for this is I'm trying to probe the server and find out which HTTP methods it is accepting ... even a GET however doesn't work from netcat which confuses me as I'm able to actually goto localhost:8080 in my browser and use the webpage as expected :(
Thanks for any insights

Your request is malformed, you need to specify the request properly:
OPTIONS * HTTP/1.1
When "HTTP/1.1" is omitted, a few servers still substitute "HTTP/0.9" there, and therefore OPTIONS won't work or just simply ignore a malformed request. Google might be forgiving on malformed requests and substitute proper data in place of the missing parameters.

Related

Nginx multiple domain/server blocks | SSL strange request character issue

We have Nginx running and multiple (around 80) server blocks/websites configured with both HTTPS and HTTP. Now adding another server blocks with website name e.g. xyz.com, then only HTTPS websites stop working. On checking the access.log, I found below logs
[23/Apr/2019:15:06:02 +0530] "\x16\x03\x01\x02\x00\x01\x00\x01\xFC\x03\x039\xAD$\xB4\xBB\x94\x98\xB8Q9\x84\xE4C\xB7\x98Z8\x9E#\x8E\xF8\xD79Jl\xA3\xAEY\xB9\xDA\x1A> \x04\xD7\x1B\xE7\x1Ch\xC3`\x81?g}\xE1y\x8D\x8E\x07\xDA;\x0F\x9D\x0B\xFF\xA2p\x0F\xB5&\xDFa\xF0\xF9\x00\x22ZZ\x13\x01\x13\x02\x13\x03\xC0+\xC0/\xC0,\xC00\xCC\xA9\xCC\xA8\xC0\x13\xC0\x14\x00\x9C\x00\x9D\x00/\x005\x00" 400 182 "-" "-"
This strange http request is getting printed for HTTPS websites hit.
What can be the possible reason for this? Is there any limit on number of server blocks files in /sites-available or /sites-enabled?
Thanks!
... "\x16\x03\x01...\x03\x03...
...This strange http request...
This is an attempt to do HTTPS on a port where you have configured HTTP. What you see is the byte sequence of a TLS 1.2 ClientHello, i.e. the start of a TLS handshake.
Now adding another server blocks with website name e.g. xyz.com, then only HTTPS websites stop working.
Likely there happened a misconfiguration while adding the new domain which caused port 443 to be plain HTTP and no longer HTTPS. Any attempt to speak HTTPS to this port (i.e. anything https://example.com since this uses 443 by default) will cause the strange entries in the access log file. Please look at the error log for hints what might have gone wrong with your configuration.

Apache configuration: effect of explicit :80 in http header field (host)

We have a server running Apache providing services via a simple API. We now stumbled upon the problem that we cannot access the API using a third-party library, altough the resulting HTTP request are ALMOST the same. The only difference - as far as we can tell from Wireshark - is the presence or absence of the explicit information about port 80. For example:
curl -d "..." http://www.example.com/foo/bar/
curl -d "..." http://www.example.com:80/foo/bar/
Both work, and Wireshark shows Host: www.example.com, i.e., without the port 80. As far as I understand cURL as well as browser or most other clients remove port 80. So far, all fine.
Now, a third-party library to make requests requires to set a port, and we need to set it to 80. If the library makes a request, Wiresharks now shows Host: www.example.com:80 - note the additional port information. This request fails, and as far as we can see in Wiresharks, this failing request only differs with respect to the host field.
Can this be a configuration issue of Apache? We currently have no direct access to the server to check the conf files. Or are we missing something completely different here.
From rfc 2616:
Host = "Host" ":" host [ ":" port ] ; Section 3.2.2
So "Host: www.example.com:80" is perfectly legitimate. But I have never seen port 80 (or 443 in the case of HTTPS) in the host field of a HTTP request. It is obviously required where the request is routed via a proxy to a non-standard port.
This would give me some concerns as to the quality of the "third-party library". My first of port of call in resolving this would be to speak to the providers of the component - they have presumably come across the problem before.
You did not mention what access you have to the library - did you check that this is not a configurable option? Do you have access to the source code, and the permission to modify it? (if not, that would imply it is commercial, paid-for software - which should give you the right to some support).
I don't know what the solution is, but some obvious things to try would be:
configure the URL at the default vhost for webserver rather than explicitly for www.example.com
or use mod_headers to rewrite the host field
or put a forward proxy in front of the webserver e.g. squid and add a url rewriter (if squid does not automatically strip the port from the host field)
Apache performs string matching with the Host field. So when the :80 is attached, the string matching will fail and Apache will consider it a URL it does not handle and reject it. That is why curl stripped it.
You can read more about the ServerName field here, which is the setting in which Apache matches against Host.
Update
So the :80 has no effect and the string matching still works.
On my production server, I did not change Apache's configuration. I wrote some quick PHP to send out the GET request on a socket, and Apache still responded correctly with the :80 attached to the Host: field.
I also checked on the server itself and see the request come in with the errant :80 attached to it and Apache answers with the status of 200 and presents the HTML.
There is something else wrong with the third party software's request.

What is yourinfo.allrequestsallowed.net?

In my apache instillation, I keep seeing the following line in my access logs:
"POST http://yourinfo.allrequestsallowed.net/ HTTP/1.1" 200
It's really freaking me out because this site is not being hosted on my server (I checked the IP just to be 100% sure). I added a "Deny all" line since the site is still in development, and now the HTTP 200 response changed to 403, like the domain is being hosted on my server.
I'm incredibly confused and scared. Does anybody know what's going on? Can I Deny all to this domain that's apparently pointing to my server?
You may want to check to make sure you don't have ProxyRequests On set anywhere where it's not supposed to. Typically a request like that is for a forward proxy and the troubling bit is that you returned a 200 response which could indicate that the request was successfully proxied.
Take a look at this wiki page about Proxy abuse.
My server is properly configured not to proxy, so why is Apache returning a 200 (Success) status code?
That status code indicates that Apache successfully sent a response to the client, but not necessarily that the response was retrieved from the foreign website.
RFC2616 section 5.1.2 mandates that Apache must accept requests with absolute URLs in the request-URI, even for non-proxy requests. This means that even when proxying is turned off, Apache will accept requests that look like proxy requests. But instead of retrieving the content from the foreign site, Apache will serve the content at the corresponding location on your website. Since the hostname probably doesn't match a name for your site, Apache will look for the content on your default host.
But it's probably worthwhile to check that you aren't proxying. Otherwise, it's not really that big of a deal.
After Jon Lin pointed me in the right direction, I figured it out.
After disabling mod_proxy and enabling mod_security, I added the following to my virtual host configuration:
SecRuleEngine On
SecRule REQUEST_LINE "://" drop,phase:1
And then restarted apache. It quits the connection and returns any amount of data, which uses less resources and bandwidth during Brute Force and DDOS attacks.
Also, it shows as an HTTP 404 Response in the access logs.
EDIT: I updated the rule to drop all types or proxies (https,https,ftp). I don't know how many protocols can be used this way, but I'd rather be safe than sorry.

I want apache give no response

I am running apache2.2 on my WinXP PC.
I want no body but a specified IP access the site.
I already use httpd.conf to deny other request.
But that's not enough, I now want to set apache to send no response, not 403.
To be simple, I want to hide my server, I don't want others know I am running a webserver.
You could bind the Apache server to localhost only. I've not tested it, but in ports.conf, you could change:
Listen 80
to
Listen 127.0.0.1:80
That would make apache bind to the IP address 127.0.0.1, which is only available from the machine itself.
This is clearly something very easy to do with a firewall, so you should try to install and configure a firewall.
On the apache side the only thing you could try is using mod_security with the "drop" action. Check this servfault answer for example. But if the connection is closed by apache an attacker could still see the connection was first accepted, so your web server is not really hidden.

Can ping ec2 server (ubuntu/apache) but don't get response from http request

Background:
OS: ubuntu
Web Server: apache2
What works:
I can ping the server's elastic IP (and receive a response)
I can ssh into the server
What doesn't work:
I cannot get any sort of http response from the server
Expected Behavior:
When I go to http://ec2-XXX-XX-XXX-XXX.compute-1.amazonaws.com/, it will serve my page, or at least give me a 404 that I can debug
Actual Behavior:
When I go to http://ec2-XXX-XX-XXX-XXX.compute-1.amazonaws.com/, it says "Oops! Google Chrome could not connect to ec2-XXX-XX-XXX-XXX.compute-1.amazonaws.com". It doesn't even give me a 404.
Rant:
Clearly the server is there because I can ssh in to that exact address and I can ping that exact IP and get a response. But when I go that exact address in my web browser it's as if it never makes it to the server. Or it's as if Amazon isn't letting http requests through, but in my security group I am clearly specifying that http requests from all sources are allowed through. Apache is definitely running, my document root is definitely set up properly, and my error and access logs don't give me anything.
Is there any sort of log in between Amazon and the server, or in between requests making it to the server and being received by Apache that would specify why it's returning "not found" rather than a 404. Can I make my Apache logs more verbose?
Thanks in advance! I've spent hours on this....
Turns out apache was set to listen on port 8080 rather than port 80, so if you encounter this problem, try taking a look at what apache's listening to.