I believe that the TLS ciphers being used are dependent on version of openSSL being used on the operating system. In my case, it appears that I don't have support for a number of the ciphers, so it won't build or run properly without them. I'm running OSX v10.12.4 (latest of Sierra). Others may have issue depending on their particular operating system and version of openSSL (if that's indeed the library that is being used by crypto/tls).

BeePing listens on port 8080 on all interfaces (including the external interface) by default.

I can submit a pull request if you'd like for the fix, but it's simply a matter of providing a specific IP and port combination to the router.Run() function. For example: router.Run("127.0.0.1:8080"). At the very least, people should be aware of it, so they aren't unknowingly opening up they internal network to enumeration by attackers ( #10 ) whenever they run a BeePing instance.

It's totally up to you, but I would suggest one of three fixes:

• Add a command-line option to accept local connections only. This is probably the most user-friendly, and depending on how you are using it at @skale-5, may fit your use case the best. This is my recommended solution.
• Set the router to listen locally automatically. This may not be how you wanted the program designed though, as it won't allow BeePing to run as an external-facing service.
• Notify users in the README.md file that BeePing listens on all interfaces by default. This way they are at least informed, and can adapt their firewall rules accordingly, if needed.

Cheers,
Aaron

Hi

we use beeping with pattern check and we would like to use regex pattern.

For example, we check Hashicorp Vault via an API call and we need to verify that multiple parameter are set.

For example, we call Vault on this URL ( https://vault/v1/sys/health ) and we get this response :

{"initialized":true,"sealed":false,"standby":false,"server_time_utc":1505381889,"version":"0.6.2","cluster_name":"vault-cluster-YYYYYY","cluster_id":"XXXXXX"}

We would like to use this regexp : .*\"sealed\":\"false\".*\"cluster_name\":\"vault-cluster.*

Thanks !

Hi

beeping doesn't seem to handle 3XX error codes. I tried with http://www.google.com :

Request :
{"url": "http://www.google.com/", "insecure": false, "timeout": 20}

Response :
{"http_status":"200 OK","http_status_code":200,"http_body_pattern":true,"http_request_time":41,"dns_lookup":3,"tcp_connection":5,"server_processing":30,"content_transfer":0,"timeline":{"name_lookup":3,"connect":9,"pretransfer":9,"starttransfer":40},"ssl":false}

but with curl :

$ curl -v http://www.google.com
* Rebuilt URL to: http://www.google.com/
*   Trying 173.194.79.99...
* TCP_NODELAY set
* Connected to www.google.com (173.194.79.99) port 80 (#0)
> GET / HTTP/1.1
> Host: www.google.com
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 302 Found
< Cache-Control: private
< Content-Type: text/html; charset=UTF-8
< Referrer-Policy: no-referrer
< Location: http://www.google.fr/?gfe_rd=cr&dcr=0&ei=Qr1DWs_uCsmD1gK11IT4Bw
< Content-Length: 268
< Date: Wed, 27 Dec 2017 15:33:22 GMT

Thanks !

It would be useful to have a header check :

• header name
• header value (regexp ?)

Thanks !

Hi

Can you, please, add support for HTTPS server-mode ? Or do you prefer we use nginx in front of beeping ?

Thanks.

Issue

It appears that we can bypass the local IP blacklist (implemented in #16) by replacing decimal characters with hex. I have tried with octal, and that didn't appear to work. Furthermore, it seems to pass some type of malformed request through when I use hex as well; this may be an issue with Gin, but I'm not 100% sure. EDIT: Turns out this was because I was trying to use HTTPS with a listener that didn't support it

BeePing listener:

HTTP listening service:

Curl requests:

Fix

My suggested fix is to cast the destination IP to an integer in the validateTarget() function, before parsing the IP with net.ParseIP(), because that function is unable to parse hex values. However, I want to be sure that we catch all test cases before doing so.

Other Notes

It's also worth tracking down what's happening with the data as it's passed through, as it appears to be corrupted or malformed somehow. When I debugged the request, the req value seemed fine (in the CheckHTTP() function), but there were two other weird values that probably shouldn't have been so off: EDIT: Ignore this, see edit above

Thanks to @jimen0 for bringing this to my attention. He may be able to chime in here as well.

Cheers,
Aaron (insp3ctre)

When I send a json in python it look like this :
{"url": "url.example.com", "insecure": "true", "timeout": "20"}
and I get "invalid json sent" from pingmeback.

Attackers commonly use proxy services (which is essentially what BeePing is) to anonymize their attack traffic. In the case of BeePing, an attacker could enumerate internet-facing web hosts or launch a DoS attack via a BeePing host, and their originating IP would not be disclosed to the target system. The "Forwarded" header has been standardized for use in these very instances, and would allow the target system to identify the true source of any attacks and respond accordingly.

I could put together a pull request to fix this issue if you'd like. Basically, I would be adding the appropriate header into each outbound request (somewhere around here. The header would look something like this: Forwarded: For=<IP>.

Cheers,
Aaron (insp3ctre)

Hi

can you, please, add an option so we can choose the listen port (8080) ?

Thanks.

Hi

I launched beeping as a simple user with this command ./beeping-v0.5.0 -listen 0.0.0.0 but port 8080 was already used.

Beeping didn't warn me with an error message and exit code was 0.

Thanks !

As detailed in #16, the application's design makes it vulnerable to server-side request forgery (SSRF). While there have already been some mitigations put into place, it would also benefit from one more- rate limiting.

Attackers can currently use an open BeePing instance to launch an anonymous DoS attack by routing a large amount of traffic through the BeePing system to the target server. While it is likely that the single BeePing instance would crash before the targeted system, it may not always be the case (if BeePing was running on a beefy, auto-scaling AWS instance, for example). By implementing rate limiting, we can limit the amount of traffic that can go through BeePing from one source, which would severely limit any types of DoS attacks through a BeePing instance.

I would recommend adding a configuration option in the future and a command-line flag now to address this. The rate can be user-customizable, but a good default would be something like 10 requests per second (per source IP). That wouldn't be enough to bring down most web servers, and it would give victims and BeePing instance operators a chance to block the source IP of the attack with a firewall rule.

You would have to track the source IPs that BeePing sees for a short period of time (only a few seconds, if the metric is requests per second) in order to check the request rate in the programming logic. A small database (in-memory or local filesystem-based) would be perfect for this use case; I've heard good things about Hashicorp's memdb and boltdb. Just be sure to properly wipe IP addresses from the database at the end of their life, as it could cause privacy concerns for users to have them long-lived.

Cheers,
Aaron (insp3ctre)

Hi,

as Chrome and Firefox last versions doesn't allow connection to SHA-1 HTTPS websites, it would be great to add an optional test to check if SSL certificate is not a SHA-1 (and other older algo which are also forbidden by Chrome or Firefox)

Thanks.