Bind to specific interface / IP address.

[don.sigm...@gmail.com]

I'm poking around the source, the box archive, and the but I haven't been able to find where I can force the railo server (tomcat?) to bind to a specific IP address or interface, instead of localhost.

I need to test some things that require network communication across multiple 'instances' and I was hoping to do this with just commandbox.  Could anyone point me in the right direction?

As a side note, maybe I should create a ticket to add that argument to the 'server start'?  something like 'server start bind=10.0.0.x'. 

[br...@bradwood.com]

Good question.  We're not using Tomcat for the servlet container, but rather Undertow which is very lightweight.  The actual HTTP listener is assigned to the server programmatically as part of our RunWAR project:

https://github.com/Ortus-Solutions/runwar/blob/master/src/runwar/Server.java#L333

 

And that setting is picked up from the system properties set by the command line args when starting the server:

https://github.com/Ortus-Solutions/runwar/blob/master/src/runwar/Server.java#L103

 

And those properties are set in the serverService when starting the server:

https://github.com/Ortus-Solutions/commandbox/blob/master/src/cfml/system/services/ServerService.cfc#L138

 

in theory, if we added a host to the server start command:

https://github.com/Ortus-Solutions/commandbox/blob/master/src/cfml/commands/server/start.cfc#L28

 

and passed it along, it would get picked up as opposed to just defaulting to 127.0.0.1

https://github.com/Ortus-Solutions/runwar/blob/master/src/runwar/options/ServerOptions.java#L10

 

Disclaimer, I didn't write the server start piece and I'm guess at how it works based on about 10 minutes of skimming the code just now :)  I'd put in a ticket for the enhancement, but feel free to play around as well.  You may be able to get it working by only modifying the start command and ServerService.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: br...@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com 

 

 

--------- Original Message ---------

--
You received this message because you are subscribed to the Google Groups "CommandBox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to commandbox+...@ortussolutions.com.
To post to this group, send email to comma...@ortussolutions.com.
Visit this group at http://groups.google.com/a/ortussolutions.com/group/commandbox/.
To view this discussion on the web visit https://groups.google.com/a/ortussolutions.com/d/msgid/commandbox/47dc21b3-5cc8-4e30-9a73-60059cbeb95e%40ortussolutions.com.
For more options, visit https://groups.google.com/a/ortussolutions.com/d/optout.

[don.sigm...@gmail.com]

Ah close, but it refuses to bind and fails.  I stripped everything down to just the command & args:

""C:\Program Files\Java\jre1.8.0_20\bin\java.exe" -Drailo.web.config.dir="C:\Users\don/.CommandBox/server//custom/checkup" -Drailo.server.config.dir="C:\Users\don/.CommandBox/server/" -javaagent:"C:\Users\don/.CommandBox/lib/railo-inst.jar" -jar "C:\Users\don\.CommandBox\lib\runwar-2.0.7.jar" -war "C:\Users\don\Desktop\webcrap\checkup" --background=false --port 56000 --host 192.168.1.100 --debug false --stop-port 56001 --processname "checkup" --log-dir "C:\Users\don/.CommandBox/server//custom/checkup/log" --open-browser true --open-url http://192.168.1.100:56000 --libdir "C:\Users\don/.CommandBox/lib" --iconpath "C:\Users\don/.CommandBox/lib/trayicon.png""

You can see the --host argument there, but in the log...

*******************************************************************
*** starting 'stop' listener thread - Host: 127.0.0.1 - Socket: 56001
*******************************************************************
Server is up - http-port:56000 stop-port:56001 PID:1376
2014-11-19 23:58:47 INFO org.xnio.Xnio <clinit> XNIO version 3.2.0.Final
2014-11-19 23:58:47 INFO org.xnio.nio.NioXnio <clinit> XNIO NIO Implementation Version 3.2.0.Final
Waiting upto 35 seconds for 192.168.1.100:56000...
could not open browser to...http://192.168.1.100:56000... timeout...

It fails there.
Also a possible issue (assuming) that the stop process would fail if it came up anyway because: https://github.com/Ortus-Solutions/runwar/blob/master/src/runwar/Stop.java the host is hardcoded there, but I could be wrong.

I'll create a ticket and reference this discussion.

[br...@bradwood.com]

Yes, I did a similar quick and unsuccessful test.  I'd have to stop and trace everything through the Java classes.  Hopefully Denny can respond on the ticket since he probably knows off the top of his head.  

--------- Original Message ---------

To view this discussion on the web visit https://groups.google.com/a/ortussolutions.com/d/msgid/commandbox/7c582a87-4525-4992-8e3f-69430ad0af9c%40ortussolutions.com.

[don.sigm...@gmail.com]

Thanks for the help Brad, ticket here: https://ortussolutions.atlassian.net/browse/COMMANDBOX-122

[don.sigm...@gmail.com]

Wanted to note something from my testing.  Using my command & args above, even though it says

Waiting upto 35 seconds for 192.168.1.100:56000...

If you visit http://localhost:56000 it works just like before, somewhere it's ignoring the host param

[denstar]

Looks like you need to update CommandBox:

>> "C:\Users\don\.CommandBox\lib\runwar-2.0.7.jar" -war

That's an older one. Should be 2.2.0, so I'm thinking that's the
problem right there.

:Denny

[br...@bradwood.com]

And to be clear, running the "upgrade" command will not update the jars.  Right now there is no automated way to do that.  What you have to do is remove the .CommandBox folder from your user directory, download the latest binary and re-execute.  it will re-extract all the jars, etc fresh.

 

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: br...@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com 

 

 

--------- Original Message ---------

Subject: Re: Bind to specific interface / IP address.

--
You received this message because you are subscribed to the Google Groups "CommandBox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to commandbox+...@ortussolutions.com.
To post to this group, send email to comma...@ortussolutions.com.
Visit this group at http://groups.google.com/a/ortussolutions.com/group/commandbox/.

To view this discussion on the web visit https://groups.google.com/a/ortussolutions.com/d/msgid/commandbox/546E7BCA.1030005%40gmail.com.

[Don Quist]

Yep!  Re-installed using the latest download with 2.2.0 and binding to that host works, just need to update the cfc's to pass the host argument along and it should work

[Brad Wood]

Excellent news.  I checked my lib folder and I also had an outdated jar which is probably why my test didn't work either. 

We'll need to figure out an update mechanism to handler updates outside of the CFML directory.  One of my ideas was to code the upgrade command to only work on dot releases, and bump a major version any time the libs got updated.  Then, enhance the binary to auto-extract itself when it's newer.

Thanks!

~Brad

ColdBox Platform Evangelist

Ortus Solutions, Corp 

E-mail: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.com

--

You received this message because you are subscribed to the Google Groups "CommandBox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to commandbox+...@ortussolutions.com.
To post to this group, send email to comma...@ortussolutions.com.
Visit this group at http://groups.google.com/a/ortussolutions.com/group/commandbox/.

To view this discussion on the web visit https://groups.google.com/a/ortussolutions.com/d/msgid/commandbox/a6a77117-7331-4b1a-b739-7b9a7cc20897%40ortussolutions.com.

[Don Quist]

My previous assumption was correct: Trying to stop the server fails because of the hardcoded 127.0.0.1 here: https://github.com/Ortus-Solutions/runwar/blob/master/src/runwar/Stop.java#L12
because https://github.com/Ortus-Solutions/runwar/blob/master/src/runwar/options/CommandLineHandler.java#L284 doesn't pass the host argument, just the port. But it's the same in the parent project from cfmlprojects

(Limited java experience, take my findings with a grain of salt.)

[br...@bradwood.com]

Good catch.  Can you add a note for that on the ticket?  Thanks for taking the time to work on this.  Also please feel free to submit a pull request for the parts you get working.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: br...@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com 

 

 

--------- Original Message ---------

Subject: Re: Bind to specific interface / IP address.

From: "Don Quist" <don.sigm...@gmail.com>
Date: 11/20/14 6:55 pm
To: comma...@ortussolutions.com
Cc: don.sigm...@gmail.com

My previous assumption was correct: Trying to stop the server fails because of the hardcoded 127.0.0.1 here: https://github.com/Ortus-Solutions/runwar/blob/master/src/runwar/Stop.java#L12
because https://github.com/Ortus-Solutions/runwar/blob/master/src/runwar/options/CommandLineHandler.java#L284 doesn't pass the host argument, just the port. But it's the same in the parent project from cfmlprojects

(Limited java experience, take my findings with a grain of salt.)

On Thursday, November 20, 2014 3:57:12 PM UTC-8, Brad Wood wrote:

Excellent news.  I checked my lib folder and I also had an outdated jar which is probably why my test didn't work either. 

 

We'll need to figure out an update mechanism to handler updates outside of the CFML directory.  One of my ideas was to code the upgradecommand to only work on dot releases, and bump a major version any time the libs got updated.  Then, enhance the binary to auto-extract itself when it's newer.

 

To view this discussion on the web visit https://groups.google.com/a/ortussolutions.com/d/msgid/commandbox/d1576c74-0be4-40f9-89a9-dbe9e54872d1%40ortussolutions.com.

[denstar]

Actually the stop socket is different than the httpport, so that should be 127.  What happens when you try to stop? Can you try runwar alone and see if it works there? You should be able to basically use the same args displayed from commandbox.

:Denny

To view this discussion on the web visit https://groups.google.com/a/ortussolutions.com/d/msgid/commandbox/20141120180025.a7243acce6934569d3743d1abfb94fec.3c945cdd63.mailapi%40email05.secureserver.net.

[Don Quist]

Below is the out log, running runwar directly for starting & stopping.  Trying to stop fails with an error message.  Also when passing -stop, the help message it spits out specifies you can pass a -host argument.
Something to note is: the server can be stopped via the tray icon.

c:\>"C:\Program Files\Java\jre1.8.0_20\bin\java.exe" -Drailo.web.config.dir="C:\Users\don/.CommandBox/server//custom/checkup1" -Drailo.server.config.dir="C:\Use
rs\don/.CommandBox/server/" -javaagent:"C:\Users\don/.CommandBox/lib/railo-inst.jar" -jar "C:\Users\don\.CommandBox\lib\runwar-2.2.0.jar" -war "C:\Users\don\Des
ktop\webcrap\checkup1" --background=false --port 56000 --host 192.168.1.100 --debug false --stop-port 56001 --processname "checkup" --log-dir "C:\Users\don/.Com

mandBox/server//custom/checkup/log" --open-browser true --open-url http://192.168.1.100:56000 --libdir "C:\Users\don/.CommandBox/lib" --iconpath "C:\Users\don/.
CommandBox/lib/trayicon.png"

2014-11-20 17:33:31 WARN RunwarLogger no attach in java.library.path
******************************************************************************
Starting - port:56000 stop-port:56001 warpath:file:/C:/Users/don/Desktop/webcrap/checkup1/
context: /  -  version: 2.2.0
web-dirs: C:\Users\don\Desktop\webcrap\checkup1
Log Directory: C:\Users\don\.CommandBox\server\custom\checkup\log
******************************************************************************
railo-server-root:C:\Users\don\.CommandBox\engine\railo\railo-server
===================================================================
SERVER CONTEXT
-------------------------------------------------------------------
- config:C:\Users\don\.CommandBox\engine\railo\railo-server\context
- loader-version:4.3
===================================================================

Thu Nov 20 17:33:31 PST 2014-740 using JRE Date Library
Thu Nov 20 17:33:32 PST 2014-143 Start CFML Controller
Thu Nov 20 17:33:32 PST 2014 Loaded Railo Version 4.2.1.008
===================================================================
WEB CONTEXT (05e06cfe06390db7f6f22abedf96e337)
-------------------------------------------------------------------
- config:C:\Users\don\.CommandBox\engine\railo\railo-web (custom setting)
- webroot:C:\Users\don\Desktop\webcrap\checkup1\
- hash:05e06cfe06390db7f6f22abedf96e337
- label:05e06cfe06390db7f6f22abedf96e337
===================================================================

******************************************************************************
*** starting 'stop' listener thread - Host: 192.168.1.100 - Socket: 56001
******************************************************************************
Server is up - http-port:56000 stop-port:56001 PID:3588 version 2.2.0
2014-11-20 17:33:32 INFO org.xnio XNIO version 3.3.0.Beta4
2014-11-20 17:33:32 INFO org.xnio.nio XNIO NIO Implementation Version 3.3.0.Beta4

Waiting upto 35 seconds for 192.168.1.100:56000...

Opening browser to...http://192.168.1.100:56000
http://192.168.1.100:56000
Thu Nov 20 17:33:35 PST 2014-653 java.lang.instrument.Instrumentation is used to reload class files


c:\>"C:\Program Files\Java\jre1.8.0_20\bin\java.exe" -jar "C:\Users\don\.CommandBox\lib\runwar-2.2.0.jar" -stop --stop-port 56001 --background false --debug true
Could not stop server.  Are you sure it is running, and listing for stop requests on port 56001?

[denstar]

I think that's a typo, it needs the stop-socket argument. See if runwar -? lists the correct parameters to use.

:Denny

--
You received this message because you are subscribed to the Google Groups "CommandBox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to commandbox+...@ortussolutions.com.
To post to this group, send email to comma...@ortussolutions.com.
Visit this group at http://groups.google.com/a/ortussolutions.com/group/commandbox/.

To view this discussion on the web visit https://groups.google.com/a/ortussolutions.com/d/msgid/commandbox/1b184354-6ad0-4d47-90b0-50045ba352d1%40ortussolutions.com.

[Don Quist]

Pretty sure -stop-socket is an alias for --stop-port: " -stopsocket,--stop-port <port>              stop listener port number. (8779)"

I went through the systray section to see why that works: https://github.com/Ortus-Solutions/runwar/blob/master/src/runwar/LaunchUtil.java#L389

as you can see, it opens up a socket using a host param from argument, which https://github.com/Ortus-Solutions/runwar/blob/master/src/runwar/Stop.java#L12 does not (the 127.0.0.1 is hardcoded here)

--

- Don Quist
www.SigmaProjects.org

[Don Quist]

Again, I'm not a java developer so can someone please verify these changes?  Pretty sure I got it correct, I built the classes and everything seemed to compile fine, but I couldn't find how to create the .jar from the included built scripts in runwar...
https://github.com/Ortus-Solutions/runwar/pull/4

To unsubscribe from this group and stop receiving emails from it, send an email to commandbox+unsubscribe@ortussolutions.com.

To post to this group, send email to comma...@ortussolutions.com.
Visit this group at http://groups.google.com/a/ortussolutions.com/group/commandbox/.

To view this discussion on the web visit https://groups.google.com/a/ortussolutions.com/d/msgid/commandbox/1b184354-6ad0-4d47-90b0-50045ba352d1%40ortussolutions.com.
For more options, visit https://groups.google.com/a/ortussolutions.com/d/optout.

[Don Quist]

Nevermind, I found the build target.  Tested my compiled runwar-2.2.0.jar - stopping the server works as expected if you pass the -host param:
"C:\Program Files\Java\jre1.8.0_20\bin\java.exe" -jar "C:\Users\don\.CommandBox\lib\runwar-2.2.0.jar" -stop --stop-port 56001 --background false --debug true -host x.x.x.x

Please accept the pull request.

[denstar]

Alright, I applied your changes Don, they're in runwar 2.2.1 if you want
to give it a spin and check.

The pull request was against a fork, so I had to grab the commit vs.
using that pull (which can be closed now if it's working).

Oh darn. Now I remember why it was supposed to be locked to localhost--
without a password as well, anyone can shut down the server by hitting
that port. The other thing I did remember, but wasn't too concerned
about, was that interfaces besides localhost can get into states that
won't let you "talk" to them, potentially starting servers without being
able to stop them. I think time would tell if that would be much of a
problem, but having the server stop when someone portscans it is. For
now we'll leave it be, but we need a password, the channel should be
over ssl probably, etc.. Thanks for your contribution, and do you have
any input on the password deal? I'm open so suggestions.

:Denny

On 11/21/2014 12:12 AM, Don Quist wrote:
> Nevermind, I found the build target. Tested my compiled runwar-2.2.0.jar -
> stopping the server works as expected if you pass the -host param:
> "C:\Program Files\Java\jre1.8.0_20\bin\java.exe" -jar
> "C:\Users\don\.CommandBox\lib\runwar-2.2.0.jar" -stop --stop-port 56001

> --background false --debug true *-host x.x.x.x*

[Luis Majano]

On Friday, November 21, 2014 at 9:36 AM, denstar wrote:

Alright, I applied your changes Don, they're in runwar 2.2.1 if you want

to give it a spin and check.

I also updated CommandBox on it as well. 

The pull request was against a fork, so I had to grab the commit vs.

using that pull (which can be closed now if it's working).

Oh darn. Now I remember why it was supposed to be locked to localhost--

without a password as well, anyone can shut down the server by hitting

that port. The other thing I did remember, but wasn't too concerned

about, was that interfaces besides localhost can get into states that

won't let you "talk" to them, potentially starting servers without being

able to stop them. I think time would tell if that would be much of a

problem, but having the server stop when someone portscans it is. For

now we'll leave it be, but we need a password, the channel should be

over ssl probably, etc.. Thanks for your contribution, and do you have

any input on the password deal? I'm open so suggestions.

I don’t know if am very concerned with it, but maybe setting a default password is good. And maybe a way to change it on a per server level is also good.

With that in mind, I have a question, (As I have not had time to digest runwar just yet).  Does undertow support SSL?  This is a key component sometimes for local development. 

:Denny

On 11/21/2014 12:12 AM, Don Quist wrote:

Nevermind, I found the build target. Tested my compiled runwar-2.2.0.jar -

stopping the server works as expected if you pass the -host param:

"C:\Program Files\Java\jre1.8.0_20\bin\java.exe" -jar

"C:\Users\don\.CommandBox\lib\runwar-2.2.0.jar" -stop --stop-port 56001

--background false --debug true *-host x.x.x.x*

Please accept the pull request.

--

You received this message because you are subscribed to the Google Groups "CommandBox" group.

To unsubscribe from this group and stop receiving emails from it, send an email to commandbox+...@ortussolutions.com.

To post to this group, send email to comma...@ortussolutions.com.

Visit this group at http://groups.google.com/a/ortussolutions.com/group/commandbox/.

To view this discussion on the web visit https://groups.google.com/a/ortussolutions.com/d/msgid/commandbox/546F7814.7080406%40gmail.com.

[denstar]

On 11/21/2014 10:39 AM, Luis Majano wrote:
> On Friday, November 21, 2014 at 9:36 AM, denstar wrote:
>> Alright, I applied your changes Don, they're in runwar 2.2.1 if you want
>> to give it a spin and check.
>>
>>
>
> I also updated CommandBox on it as well.

Cool, so just check the latest CommandBox Don, if you're up to it.

...

>> over ssl probably, etc.. Thanks for your contribution, and do you have
>> any input on the password deal? I'm open so suggestions.
>>
>>
>
> I don’t know if am very concerned with it, but maybe setting a default password is good. And maybe a way to change it on a per server level is also good.

It certainly needs to be protected somehow-- random shutting down of
servers, development or production, is never fun.

I think maybe only allowing binding the stop listener to external
interfaces if a password has been set, otherwise having it use localhost
might work.

Gonna have to think about it a bit. Don't really want to pass passwords
around either.

> With that in mind, I have a question, (As I have not had time to digest runwar just yet). Does undertow support SSL? This is a key component sometimes for local development.
>>

Sure undertow will do SSL. I haven't added that to runwar though.
Shouldn't be too hard to add, he says famously.

:Denny

[Luis Majano]

Denny,

Can you give me an estimate to add SSL support right now. I think we need this, at least for our internal projects we do.

Luis Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com

ColdBox Platform: http://www.coldbox.org
ContentBox Platform: http://www.gocontentbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Social: twitter.com/ortussolutions | twitter.com/coldbox | twitter.com/lmajano | twitter.com/gocontentbox

[br...@bradwood.com]

Here's a link showing how to add an HTTPS listener to Undertow via the XML config files.

 

http://stackoverflow.com/questions/24305910/how-to-add-https-listener-to-wildflys-default-server

 

I assume it's just a matter of find the matching programmatic configuration.  Denny, do you have any links that documents the API run war uses to bootsrap the servlets and listeners?  My Googling has always turned up nothing more than flimsy marketing pages on the JBoss site extolling the high-level virtues of Undertow (and Wildfly) but it seems a lot harder to actually unearth their Java docs, or API docs for programmatic configuration like we're doing.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: br...@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com 

 

 

--------- Original Message ---------

Subject: Re: Bind to specific interface / IP address.

[Don Quist]

I was looking at the undertow doc http://undertow.io/documentation/servlet/security.html
Maybe use the Authorization header with a random hash, then that could be passed around internally to runwar (and by extension saved to commandboxs server info json) instead of a password.  But I don't see how to apply this to Only the stop socket

[denstar]

Say 2-4, probably about 3 hours to add SSL. Want me to create a ticket?

:Denny

On 11/21/2014 10:53 AM, Luis Majano wrote:
> Denny,
>
> Can you give me an estimate to add SSL support right now. I think we need this, at least for our internal projects we do.
>
>
>

> Luis Majano
> CEO
> Ortus Solutions, Corp

> www.ortussolutions.com (http://www.ortussolutions.com)
>
> ColdBox Platform: http://www.coldbox.org (http://www.coldbox.org/)
> ContentBox Platform: http://www.gocontentbox.org (http://www.gocontentbox.org/)
> Linked In: http://www.linkedin.com/pub/3/731/483
> Social: twitter.com/ortussolutions (http://twitter.com/ortussolutions) | twitter.com/coldbox (http://twitter.com/coldbox) | twitter.com/lmajano (http://twitter.com/lmajano) | twitter.com/gocontentbox (http://twitter.com/gocontentbox)

[br...@bradwood.com]

Denny, can you explain how the stop socket works?  You said just sending a packet to that port on that interface is enough to trigger the shutdown?

Is this a J2EE or servlet thing, or something of your own design?  What OSI network level is this happening at?  Is it literally just ethernet frames in the form of a TCP packet, or is an HTTP request being sent to this port?  

 

Also, when you say password, are you thinking of some plain text string that's streamed to that port?  Would the user need to type it, or would we just randomly generate something and store it in servers.json for that server and pass it to prove we're friendly?   Where would we write the code to see what was passed to the stop socket?

 

I'm just trying to understand how it works and what pieces we have control over.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: br...@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com 

 

 

--------- Original Message ---------

Subject: Re: Bind to specific interface / IP address.

[br...@bradwood.com]

Hmm, a bit of Googling might have answered my question-- or at least in the context of Tomcat:

 

http://www.avajava.com/tutorials/lessons/how-do-i-prevent-people-from-shutting-down-my-tomcat.html?page=2

 

It appears you just open a socket connection to that port (like with telnet) and send that text followed by a carriage return.  I'm unclear on if that's just a Tomcat implementation, or the general spec that all servlet containers follow.

 

If that's true, then I don't see how a portscan would shut down your server.  If undertow works the same way, just generate a random shutdown string and store it. 

--------- Original Message ---------

--

You received this message because you are subscribed to the Google Groups "CommandBox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to commandbox+...@ortussolutions.com.
To post to this group, send email to comma...@ortussolutions.com.
Visit this group at http://groups.google.com/a/ortussolutions.com/group/commandbox/.

To view this discussion on the web visit https://groups.google.com/a/ortussolutions.com/d/msgid/commandbox/20141121112400.a7243acce6934569d3743d1abfb94fec.b41c0fceec.mailapi%40email05.secureserver.net.

[denstar]

WildFly == JBoss AS, which has freaking oodles more cool stuff than
stock Undertow comes with. So you'll see lots of stuff for WF, vs.
Undertow itself, which is intentionally bare-bones.

As for the Undertow API, it's pretty straightforward. I haven't needed
more than the tests and source code. The docs on the site cover the
basics, FWIW.

I'm obviously not a visual learner though-- I strive to write code that
is self-documenting. ;)

Start at the tests though, they have good coverage, and examples too.

:Denny

[denstar]

On 11/21/2014 11:11 AM, Don Quist wrote:
> I was looking at the undertow doc
> http://undertow.io/documentation/servlet/security.html
> Maybe use the Authorization header with a random hash, then that could be
> passed around internally to runwar (and by extension saved to commandboxs
> server info json) instead of a password. But I don't see how to apply this

> to *Only* the stop socket
>

Hrm, yeah. I like that train of thought though. Keep 'em coming!

:Denny

[denstar]

On 11/21/2014 11:27 AM, br...@bradwood.com wrote:
> Hmm, a bit of Googling might have answered my question-- or at least
> in the context of Tomcat:
>
> http://www.avajava.com/tutorials/lessons/how-do-i-prevent-people-from-shutting-down-my-tomcat.html?page=2
>
> It appears you just open a socket connection to that port (like with
> telnet) and send that text followed by a carriage return. I'm
> unclear on if that's just a Tomcat implementation, or the general
> spec that all servlet containers follow.

They do different things to achieve the same ends. Some have listeners,
some have watchdogs, but conceptually they do the same thing.

And yep, ours just listens for a carriage return.

>
> If that's true, then I don't see how a portscan would shut down your
> server. If undertow works the same way, just generate a random
> shutdown string and store it.

Generally, if they find an open port they immediately try to do stuff
with it, and a carriage return isn't exactly unique. :)

Generating a random "password" if one wasn't specified wouldn't work
because the user wouldn't know what it was, right?

How were you thinking of storing it?

:Denny

[Don Quist]

I'm snailing along a demo of how to prevent randoms from killing the server, using brads idea:

add property in ServerOptions.java to contain a "stopAuth" - have it a randomly generated hash

in Server.java in the stop MonitorThread compare the incoming readLine() with the stopAuth

if it matches, run the rest to stop.

And this way doesn't even have to concern commandbox, so it doesn't have to get messy there.

If this sounds good it could be implemented by someone a lot faster than I'm trying now.

--
You received this message because you are subscribed to the Google Groups "CommandBox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to commandbox+...@ortussolutions.com.
To post to this group, send email to comma...@ortussolutions.com.
Visit this group at http://groups.google.com/a/ortussolutions.com/group/commandbox/.

To view this discussion on the web visit https://groups.google.com/a/ortussolutions.com/d/msgid/commandbox/546F8A19.20402%40gmail.com.

For more options, visit https://groups.google.com/a/ortussolutions.com/d/optout.

[br...@bradwood.com]

Authorization headers assign that the stop signal is coming across HTTP, but it's not right?  It's just a TCP connection that streams a string of letters from what I've seen.  From what I've seen, stop connections appear to operate at a lower network level that HTTP.  

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: br...@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com 

 

 

--------- Original Message ---------

Subject: Re: Bind to specific interface / IP address.
From: "denstar" <vallia...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "CommandBox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to commandbox+...@ortussolutions.com.
To post to this group, send email to comma...@ortussolutions.com.
Visit this group at http://groups.google.com/a/ortussolutions.com/group/commandbox/.

To view this discussion on the web visit https://groups.google.com/a/ortussolutions.com/d/msgid/commandbox/546F885C.7090301%40gmail.com.

[Don Quist]

Yeah, the doc I linked earlier was wrong, this is just an open socket waiting for a return carriage (Ctrl-C)

To view this discussion on the web visit https://groups.google.com/a/ortussolutions.com/d/msgid/commandbox/20141121115908.a7243acce6934569d3743d1abfb94fec.4c143a25cd.mailapi%40email05.secureserver.net.

For more options, visit https://groups.google.com/a/ortussolutions.com/d/optout.

[br...@bradwood.com]

> Generally, if they find an open port they immediately try to do stuff
> with it, and a carriage return isn't exactly unique. :)

Well, there's a difference between saying "a portscan will shutdown the server" and saying a person with malicious intent "can easily guess how to shut down the server'

Is the carriage return just how Undertow works, or is there Java code somewhere that you wrote that is the listener?

> Generating a random "password" if one wasn't specified wouldn't work
> because the user wouldn't know what it was, right?

 

I assumed this wouldn't anything we'd bother the user with.  The "password" would simply be generated and used behind the scenes.

 

> How were you thinking of storing it?

 

In servers.json where we store the shutdown port, etc.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: br...@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com 

 

 

--------- Original Message ---------

Subject: Re: Bind to specific interface / IP address.
From: "denstar" <vallia...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "CommandBox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to commandbox+...@ortussolutions.com.
To post to this group, send email to comma...@ortussolutions.com.
Visit this group at http://groups.google.com/a/ortussolutions.com/group/commandbox/.

To view this discussion on the web visit https://groups.google.com/a/ortussolutions.com/d/msgid/commandbox/546F8A19.20402%40gmail.com.

[br...@bradwood.com]

Also, see this related ticket I got around to putting in today.  This has been bugging me for a while:

 

https://ortussolutions.atlassian.net/browse/COMMANDBOX-123

--------- Original Message ---------

To view this discussion on the web visit https://groups.google.com/a/ortussolutions.com/d/msgid/commandbox/CAALP6duCLS-m2Yi4z%2Bpfed-5vrcAF3RSfAZN1%2B33MWooZgUvsQ%40mail.gmail.com.

[Brad Wood]

On Fri, Nov 21, 2014 at 12:57 PM, Don Quist <don.sigm...@gmail.com> wrote:

And this way doesn't even have to concern commandbox, so it doesn't have to get messy there.

Actually, it may need to involve CommandBox so the server status in servers.json can be kept up to date. This is issue in that ticket I linked to earlier where bypassing CommandBox to shut down a server is already causing issues.  

[Don Quist]

You're right Brad.  To include a stop auth code and travel through commandboxs execute() command, it would need to be stored somewhere (like the CmdB server json).
I was hoping for a secure solution without having to completely diverge the 2 projects with this single feature.  Oh, or maybe just default the stopAuth to be \r\n. 

sound good to you Denny?

[denstar]

I think we have a plan of attack. Wouldn't hurt to check some existing
implementations before rolling it.

:Denny

On 11/21/2014 12:37 PM, Don Quist wrote:
> You're right Brad. To include a stop auth code and travel through
> commandboxs execute() command, it would need to be stored somewhere (like
> the CmdB server json).
> I was hoping for a secure solution without having to completely diverge the
> 2 projects with this single feature. Oh, or maybe just default the
> stopAuth to be \r\n.
>
> sound good to you Denny?
>
> On Fri, Nov 21, 2014 at 11:12 AM, Brad Wood <bdw...@gmail.com> wrote:
>
>>
>> On Fri, Nov 21, 2014 at 12:57 PM, Don Quist <don.sigm...@gmail.com>
>> wrote:
>>
>>>
>>> And this way doesn't even have to concern commandbox, so it doesn't have
>>> to get messy there.
>>>
>>
>> Actually, it may need to involve CommandBox so the server status in
>> servers.json can be kept up to date. This is issue in that ticket I linked
>> to earlier where bypassing CommandBox to shut down a server is already
>> causing issues.
>>
>> Thanks!
>>
>> ~Brad
>>

>> *ColdBox Platform Evangelist*
>> *Ortus Solutions, Corp *

[denstar]

On 11/21/2014 12:02 PM, br...@bradwood.com wrote:
>> Generally, if they find an open port they immediately try to do
>> stuff with it, and a carriage return isn't exactly unique. :)

> Well, there's a difference between saying "a portscan will shutdown
> the server" and saying a person with malicious intent "can easily
> guess how to shut down the server' Is the carriage return just how
> Undertow works, or is there Java code somewhere that you wrote that
> is the listener?

While you can do a port scan that only checks listening ports, vs.
sending any data or trying to figure out what is running on those ports,
the automated tools aren't in general very, um, restrained, and will
indeed try to determine the services running on the open ports. I
should have been more specific, but it happens literally all the time--
just take a gander at any server logs. :)

The listener just reads a line (waits for a CR), basically:

https://github.com/cfmlprojects/runwar/blob/master/src/runwar/Server.java#L448

>> Generating a random "password" if one wasn't specified wouldn't
>> work because the user wouldn't know what it was, right?
>
> I assumed this wouldn't anything we'd bother the user with. The
> "password" would simply be generated and used behind the scenes.

It has to get passed back in somehow, so it has to go out somehow.

It could be like the PID, which you only know /after/ you start the
program-- we just change the output to be "to stop the server, use blah
blah -stop -stoppassword gennedPass" or some such.

I dunno... we'll never think up all the stuff that other people have
already tackled (or I don't want to try :]), so I'll look around and see
what issues other folks have run into trying to do the same thing, and
get a lay of the terrain as it were.

:Denny

[Don Quist]

I just looked at Tomcat and they use a shutdown property in their server.xml https://github.com/apache/tomcat/blob/614db1001f6470979725f660697df021276219da/conf/server.xml#L22

indicated by their config: https://github.com/apache/tomcat/blob/614db1001f6470979725f660697df021276219da/java/org/apache/catalina/Server.java#L40

which is written to the shutdown socket here: https://github.com/apache/tomcat/blob/614db1001f6470979725f660697df021276219da/java/org/apache/catalina/startup/Catalina.java#L454

then is read by...somewhere, I can't find where it's read from, that's a huge project.

:Denny

--
You received this message because you are subscribed to the Google Groups "CommandBox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to commandbox+...@ortussolutions.com.
To post to this group, send email to comma...@ortussolutions.com.
Visit this group at http://groups.google.com/a/ortussolutions.com/group/commandbox/.

To view this discussion on the web visit https://groups.google.com/a/ortussolutions.com/d/msgid/commandbox/546F9D5E.6070202%40gmail.com.

For more options, visit https://groups.google.com/a/ortussolutions.com/d/optout.

[br...@bradwood.com]

I guess perhaps we should decide if we want to:

• Prevent accidental shutdowns from some well-intentioned process on your internal network
• Secure your server from malicious intent in case they're publicly exposed

CommandBox is a development tool so I think its reasonable to expect it to only used inside trusted, internal networks.   In that scenario, I'd just set some one-time string and hardcode it.  It's not "security" per se, just a big of accident-proofing to filter out miscellaneous connections from creating false-positives.  

 

I don't know how likely it is that people will be running embedded CommandBox servers on a public network, and if they do I don't know that it's really our fault.  If we're going to try and harden the embedded server to make it secure for public access, that really sounds more comprehensive and a lot of work.  I'd be tempted to simply say, "the embedded server is not secure-by-default and for internal use".  That's basically that stuff like XAMPP does.  Heck, they leave your MySQL root password blank and just tell you that it's not for production use.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: br...@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com 

 

 

--------- Original Message ---------

Subject: Re: Bind to specific interface / IP address.
From: "denstar" <vallia...@gmail.com>

[Don Quist]

"the embedded server is not secure-by-default and for internal use" - is my thoughts on it as well.  I don't see CmdB/Runwar trying to replace a full Railo or ACF installation on a public facing machine (though I could see some people trying).  So I don't imagine it's worth it to try and secure a simple dos vulnerability

*I'm just a dev who understands the tools and uses 'correctly', my opinion shouldn't carry much weight

To view this discussion on the web visit https://groups.google.com/a/ortussolutions.com/d/msgid/commandbox/20141121133907.a7243acce6934569d3743d1abfb94fec.88f07159c5.mailapi%40email05.secureserver.net.

For more options, visit https://groups.google.com/a/ortussolutions.com/d/optout.

[denstar]

Keeping it in a config file might be the direction to go, in
WEB-INF/runwar.json or some such. I'd just added some stuff that would
make that pretty doable.

:Denny

[denstar]

On 11/21/2014 01:49 PM, Don Quist wrote:
> "the embedded server is not secure-by-default and for internal use" - is my
> thoughts on it as well. I don't see CmdB/Runwar trying to replace a full
> Railo or ACF installation on a public facing machine (though I could see
> some people trying). So I don't imagine it's worth it to try and secure a
> simple dos vulnerability

I use runwar "in real life" so it's important to me. :)

It can outperform a "full" install, and is great for limited resources
(VMs and such, similar to jetty-runner).

There are a lot of benefits to a bare-bones container, just as there are
a lot of benefits to containers like WildFly. So while commandbox isn't
aiming at "production level" serving capability, runwar is. Not all
hard-core-like, but more than just phoning it in. Middle'n it. :)

> *I'm just a dev who understands the tools and uses 'correctly', my opinion
> shouldn't carry much weight

You carry weight by the very fact of being a squirrel trying to get a
nut, so to speak, which is why we're all here, so be assured that your
input is quite valuable. Thanks for taking the time to share it hombre!

:Denny

[Luis Majano]

Denny I love your analogies. 

Anyways I am with Denny in the fact that runwar should be a production capable server. So I am all for it. 

Luis Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com

P/F: 1-888-557-8057

Direct: (909) 248-3408

ColdBox Platform: http://www.coldbox.org

ContentBox Platform: http://www.gocontentbox.org

Linked In: http://www.linkedin.com/pub/3/731/483

Social: twitter.com/ortussolutions | twitter.com/coldbox | twitter.com/lmajano | twitter.com/gocontentbox

--
You received this message because you are subscribed to the Google Groups "CommandBox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to commandbox+...@ortussolutions.com.
To post to this group, send email to comma...@ortussolutions.com.
Visit this group at http://groups.google.com/a/ortussolutions.com/group/commandbox/.

To view this discussion on the web visit https://groups.google.com/a/ortussolutions.com/d/msgid/commandbox/546FB6BF.10106%40gmail.com.

[Don Quist]

I just realized CommandBox could use java directly to open a socket and write to the stop socket runwar is listening on.  Just throwing an option out there.

[Luis Majano]

I think is the other way around. Basically for the launcher stop command it must advice commandbox about it, so it can change its status to stopped.

Luis Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com

P/F: 1-888-557-8057

Direct: (909) 248-3408

ColdBox Platform: http://www.coldbox.org

ContentBox Platform: http://www.gocontentbox.org

Linked In: http://www.linkedin.com/pub/3/731/483

Social: twitter.com/ortussolutions | twitter.com/coldbox | twitter.com/lmajano | twitter.com/gocontentbox