First post on this forum,
I work on an offline network with a lot of computers on an active directory. I would like to automatically update Windows on all of them. I found WSUS offline but it only works on a single computer. I also found WSUS Server but from what I understood, it needs to be connected to another WSUS machine with Internet (which is not possible for me).
What I wish to do is a mix between them: being able to download updates on a computer, transfer them manually to a WSUS Server, and change the windows update source through GPO to my WSUS Server.
I've found other software like batchpatch or autopatcher but none of them could do that.
Does anyone know if it is possible ?
Yes, you can configure a WSUS server to operate offline, check the MS documentation regarding this:
https://learn.microsoft.com/de-de/security-updates/windowsupdateservices/18127442
Hope this help
I have a Django web app running in a Docker container which in due course will run live in an AWS EC2 instance (but for development is running on my Windows 10 laptop).
As the web app wants to send emails for various reasons, I would like to know the simplest approach for this, both for AWS operation, presumably using Amazon's Simple Email Service (SES), and for my development.
Having read that the Docker container needed to include an SMTP relay, I spent some time setting up the neat looking relay at https://hub.docker.com/r/turgon37/smtp-relay
But despite the claimed simplicity of the config setup, I had trouble with this (probably my fault, although the documentation was somewhat ambiguous in places as it was obviously written by someone whose native language is not English!). More to the point, it occurred to me that the claim an SMTP relay was needed in the container may have been nonsense, because surely one can just map container port 25 to the host's port 25 ?!
So in summary, has anyone had this requirement, i.e. for using SMTP in a Docker container, and what is the simplest approach?
TIA
Regards
John R
I have been trying to setup Docker in Windows Server 2016 in an AWS instance to run an IIS program.
From this question,
Cannot access an IIS container from browser - Docker, IIS has been setup inside a container and it is accessible from the host without port mapping.
However, if I want to allow other users from the Internet/Intranet to access the website, after Google-ing it, I guess we do need port mapping...
The error I have encountered in port mapping is given in the above question so... I guess using nat is not the correct option. Therefore, my team and I tried to create another network (custom/bridge) following instructions from
https://docs.docker.com/v17.09/engine/userguide/networking/#user-defined-networks
However, we cannot create a network as follows:
; Googled answer:
https://github.com/docker/for-win/issues/1960
My team guessed maybe its because AWS blocked that option, if anyone can confirm me, please do.
Another thing that I notice is: when we create an ECS instance in AWS,
So... only default = NAT network mode is accepted in Windows server?
Our objective: put the container hosted IIS application to Internet/Intranet in Windows Server 2016...
If anyone has any suggestion/advice, please tell me, many thanks.
I have RAILO (Railo 3.1.2.001 final) installed on an AMAZON EC2 instance and everything seems to be working fine for the tests I have done. I can connect to mySQL and simple commands work. The applications I am planning to run on it make extensive use of CFFTP to pull files in from clients and process them. The OPEN command works fine and I get a succeeded in Active and Passive mode, but when I try to do anything (check for a file, put a file, download) I get : 500 Illegal PORT command.
My thought here is the AMAZON firewall is blocking some ports and something needs to be setup for this to function.
Anyone have any experience with this and can point me in the correct direction?
Thanks in advance,
Jeff
do you connect from outside amazon to the instance ? if you do check the security group and allow the ip/port for your application.
We have a product we are deploying to some small businesses. It is basically a RESTful API over SSL using Tomcat. This is installed on the server in the small business and is accessed via an iPhone or other device portable device. So, the devices connecting to the server could come from any number of IP addresses.
The problem comes with the installation. When we install this service, it seems to always become a problem when doing port forwarding so the outside world can gain access to tomcat. It seems most time the owner doesn't know router password, etc, etc.
I am trying to research other ways we can accomplish this. I've come up with the following and would like to hear other thoughts on the topic.
Setup a SSH tunnel from each client office to a central server. Basically the remote devices would connect to that central server on a port and that traffic would be tunneled back to Tomcat in the office. Seems kind of redundant to have SSH and then SSL, but really no other way to accomplish it since end-to-end I need SSL (from device to office). Not sure of performance implications here, but I know it would work. Would need to monitor the tunnel and bring it back up if it goes done, would need to handle SSH key exchanges, etc.
Setup uPNP to try and configure the hole for me. Would likely work most of the time, but uPNP isn't guaranteed to be turned on. May be a good next step.
Come up with some type of NAT transversal scheme. I'm just not familiar with these and uncertain of how they exactly work. We have access to a centralized server which is required for the authentication if that makes it any easier.
What else should I be looking at to get this accomplished?
Is there no way this service can by hosted publicly by you or a hosting provider rather than with the customer?
I had a similar situation when I was developing kiosks. I never knew what type of network environment I'd have to deal with on the next installation.
I ended up creating a PPTP VPN to allow all the kiosks to connect to one server I hosted publicly. We then created a controller web service to expose access to the kiosks that were all connected via the VPN. I'm not sure how familiar you are with VPN's but with the VPN connection I was able to completely circumvent the firewall in front of each kiosk by accessing the kiosk via the VPN assigned IP.
Each kiosk node was incredibly easy to setup once I had a VPN server setup. It also brought management benefits and licensing revenue I originally didn't think about. with this infrastructure I was easily able to roll out services accessible via mobile phones.
Best of luck!
Solutions exist to "dynamically" access a software on a computer behind a NAT, but usually mostly for UDP communication.
The UDP hole punching technique is one of them. However, this isn't guranteed to work in every possible situation. If both sides of the communication are behind a "Symmetric Cone NAT" it won't.
You obivously can reduce the probability a client can't communicate using UPnP as a backup (or even primary) alternative.
I don't know Web Services enough and don't even know if using UDP for your webservice is an option (or if it is even possible).
Using the same technique for directly TCP is likely to fail (TCP connections aren't stateless - that causes a lot of problems here).
An alternative using the same technique, would be to set up some VPN based on UDP (just like OpenVPN), but as you stated, you'll have to manage keys, certificates, and so on. This can be automated (I did it) but still, it's not really trivial.
===EDIT===
If you really want to use TCP, you could create a simple "proxy" software on the client boxes which would serve as a relay.
You would have the following schema:
Web Service on client boxes, behind a NAT
The "proxy" software on the same boxes, establishing an outgoing (thus non-blocked) TCP connection to your company servers
Your company servers host a WebService as well, which requires a something like a "Client Identifier" to redirect the request to the adequate established TCP connection.
The proxy program interrogates the local WebService and send back the response to the company servers, which relay the response to the originate requester as well.
An alternative: you might ask the proxy software to directly connect to the requester to enhance performance, but then you might encounter the same NAT problems you're trying to avoid.
It's things like this that are the reason people are tunneling everything over http now, and why certain hardware vendors charge a small fortune for Layer 7 packet filtering.
This is a tremendous amount of work to fix one problem when the customer has at least three problems. Besides the one you've identified, if they don't know their own password, then who does? An administrator who doesn't work there anymore? That's a problem.
Second, if they don't know the password, that means they're almost certainly far behind on firmware updates to their firewall.
I think they should seriously consider doing a PROM reset on their firewall and reconfiguring from scratch (and upgrading the firmware while they're at it).
3 birds, one stone.
I had to do something similar in the past and I believe
the best option is the first one you proposed.
You can do in the easy way, using ssh with its -R option, using
publick key auth and a couple of scripts to check for
connectivity. Don't forget the various keep alive and timeout
features of ssh.
Don't worry about the performances. Use unprivileged users and ports
if you can. Don't bother to setup a CA, the public key of each remote
server is easier to maintain unless you are in the thousands.
Monitoring is quite simple. Each server should test the service on the
central server. If it fails either the tunnel is down or there's no connectivity.
Restarting the tunnel will not harm in any case.
Or you can do it at the network level, using IPsec (strongswan).
This can be trickier to setup and it's the option I used but I will
use SSH the next time, it would have saved me a lot of time.
+1 for going with a SSH tunnel. It's well known, widely available and not too hard to configure.
However, as you point out, you are running SSL already, so the SSH encryption is redundant. Instead of SSH you could just use a regular tunneling proxy, that provides the tunnelling without the encryption. I've used this one in the past, and it has worked well, although I didn't load test it - it was used with just a handful of users.
Here's a blog from someone who used the tunnelling proxy to access his webcam from outside his firewall.
Set up an Apache in front of your Tomcat. This Apache should be visible from the internet, where the Tomcat should not.
Configure Apache to forward all traffic to the Tomcat. This can easily be accomplished using mod_proxy (check out the ProxyPass and ProxyPassReverse directives).
Have your SSL certificate located in the Apache, so that all clients can talk HTTPS with the Apache server, which in turn talks plain HTTP with Tomcat.
No tunneling or other nastyness + you will be surprised how easy it is to configure Apache to do this.
If you want to have a RESTful integration to the client server, a tunnel to the central server that works as a proxy, seems the best approach.
But if this is not a hard requirement, you can let the central server handle the RESTfull stuff and integrate the central server and client server with other middleware. Good candidates would be RMI or JMS. For example, a RMI connection initiated by the client allows the server to do RMI calls to the client.
You could try to connect to an pc/ server and tunnel all the data via hamachi (Free VPN Software) because this tool you can install and it will create a reverse connection (from inside your nat to outside) so you can connect to it
site: http://hamachi.cc/