I'm trying to get around a 3rd-party firewall that blocks non HTTP traffic. I have a mAP installed on the customer's network and I typically have such devices connect to my server via Wireguard - but the traffic is blocked by their firewall. And I'm having difficulties working with the corporate firewall administration. I'm hoping they'll approve opening the ports I need but even if they do it's made me think about how I can safeguard for the future.
So...since outbound traffic on port 443 is allowed I'm thinking of trying to use that. However, my server already provides HTTP/S services so port 443 is being used. So I can theoretically identify the customer's IP with a filter - but I'd rather not have a site-specific rule for a remote if I can avoid it. Instead...I'm thinking maybe port knocking might be a solution.
The corporate firewall also blocks ICMP - so I can't use ping. I know how to setup port knock "listening" on my router - what I don't know is how to perform the "knocks" using Mikrotik scripts especially without ping. I know ports 80 and 443 are available for outbound, possibly also 53 and 25, but I don't know how to do that apart from telnet and I don't think I can script telnet to abort immediately.
See https://github.com/shadowsocks/v2ray-plugin. Put this inside container and use port knocking to open https port. This build works on ROS container: https://hub.docker.com/r/teddysun/go-shadowsocks2I'm trying to get around a 3rd-party firewall that blocks non HTTP traffic.
the obvious question is : who are you and what is your relationship with the company?And I'm having difficulties working with the corporate firewall administration. I'm hoping they'll approve opening the ports I need but even if they do it's made me think about how I can safeguard for the future.
even if there is port knocking in MT or in other vendors - your question description is too obvious that the company simply don't trust you, be it other vendors resident engineer who stayed there to run the security subsection nor local operator.
Is there a way to generate a port knock from within RouterOS?
You seem to have been lucky so far to only meet customers that are small enough and/or competent enough that setting up remote access for contractors is a fast process. Believe me or not, it is not always the caseyour question description is too obvious that the company simply don't trust you
having difficulty in market penetration, doesn't mean you have to push your luck to the edge.Believe me or not, it is not always the case
Yes, sry I misread OT, you can use fetch tool on ROS and send some "secret" data in http-data to with http-method post to port 80. Using Layer7 protocol in firewall rule you can parse / verify that data and then add source to expiring address list, similar to this https://wiki.mikrotik.com/wiki/Port_Knocking.Thank you but none of this answers my question. Is there a way to perform a "knock" from within RouterOS?
This...is extraordinarily helpful and precisely what I was asking for. Thank you.Port knocking on TCP ports is as easy as using /tool fetch url="http://ip.to.be.knocked:port-to-be-knocked/some-bogus-file-name", and port knocking on UDP ports is as easy as using resolve some.bogus.string.with.dots server=ip.to.be.knocked port=port-to-be-knocked. But there are limitations - to restrict the number of packets that will be sent, you have to create some firewall rules in the output chain.
Other than that - even strict firewall administrators often permit access to TCP/8443.
If you want exactly one packet, and the output and postrouting chains are currently empty in all tables, it would be something likeCan you give me an example of an appropriate output rule?
When sending some defined data in udp payload using layer7 protocol in filter it is possible to parse content and add src address if matched to allow list (with some dst-limit rule to be sure).In larger companies, a pool of public addresses is sometimes used for src-nat, so the port knock may arrive from a different address than the actual SSTP connection attempt.
This idea is great! Given the timeouts, it may take quite long (minutes) to collect them all, but on the other hand, as this is not port knocking per se (the purpose here is not to only allow incoming connections within a few seconds after the knock), this may not be important.There is a chance when sending multiple udp payloads with traffic generator in some period with same data...
I've done some sniffing and it looks promising. Using different certificates for the HTTPS and for the SSTP should make the distinction even easier as if the SSTP client is unable to verify the server certificate, it terminates the connection sooner so the distinction might be more reliable even if the exact number of bytes changes after some RouterOS upgrade.I also think it might be possible to distinguish an incoming SSTP connection attempt from an incoming HTTPS request using connection-bytes match condition together with tcp-flags=fin