Re: Need help with SecurityManager and errors thrown by JT400 classIFSFile

[Charles Wilt <charles.wilt@xxxxxxxxx>]

Bill,

Unless there's something super sensitive about the application, allowing any
connection from the internal network seems reasonable.  Not only is
maintaining the allowed IPs going to be extra work,  I'd assume your
desktops use DHCP, which means the IPs could change!

Just doesn't make sense to me to limit the connections to whitelisted IPs
when the app is designed for use by users at there desktop.

Instead, isn't there some way you could blacklist an IP temporarily?  So run
the penitration team does there thing, they'll get connection a few time but
after so many invalid attemps, you'll stop accepting connections from that
IP.

As a plus, your app will still be protected if the penetration team happens
to be working from a PC that you were going to whitelist originally; or if
in the real world that users PC is actually compromised.

Just a thought.

Charles

On Thu, Jun 25, 2009 at 3:29 PM, Blalock, Bill <Bill.Blalock@xxxxxxxx>wrote:

> Thanks for your interest Charles and Peter.
>
> Charles is right, I was wrong about
>
> > > -        allow it to listen only on port 3111
>
> Isn't anything I need to be concerned with.  "MY" program will listen to
> only the ports I tell it to.  Restricting "MY" program to listen to only
> that port won't do anything to stop the "penetration tests" because it
> isn't listening to any ports I haven't already told it to.
>
> The problem is that I assumed when writing the program "anyone"
> connecting on port 3111 is valid and tried to connect.  I assumed it was
> safe since the i5 is on a private network behind multiple firewalls --
> silly me!  The penetration tests come along, find something is listening
> on the i5 at that port and pound on it.
>
> Drew
>
> > > but isn't it possible to have a timeout when listening on a port,
> > > like you can with a data queue?  Then the program could listen to
> > > 1 port for say 500ms, and if nothing arrived, listen on the other
> > > port for 500ms, etc.
>
> It is easier write the class which listens to the port to extend Thread
> or implement Runnable and start it in its own thread as Charles
> suggests.  That way the rest of the application keeps on doing its thing
> while the instance of the class(es) wait for something to arrive on the
> port.
>
> The challenge is to ignore that attempts to connect to the port that
> isn't a list of client computers.
>
> - This could be done by the class which listens to the thread.
> - It can be done by implementing SecurityManager and granting "connect"
> permission to the client computers.
> - Someone else has suggested I look at JTOpen Permissions class (haven't
> done that but intend to.
>
> I seem to have gotten around the problem I requested help for, not quite
> sure which which fixed it.  I'll post the solution, which I am still
> testing, in case it helps anyone else
>
> 1.      Add these two properties to RUNJVA PROP parameter
>        (java.security.manager)
>        (java.security.policy 'sysmon.policy')
> 2.      sysmon.policy has these entries:
> // general permissions
> grant {
>  permission java.util.PropertyPermission "*", "read,write";
>  permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
>  permission java.lang.RuntimePermission "*";
>  permission javax.net.ssl.SSLPermission "getSSLSessionContext";
>  permission java.io.FilePermission
> "/QIBM/ProdData/Java400/jdk15/lib/-", "read";
>
> // Socket permissions to let Java work
>  permission java.net.SocketPermission "localhost:0-1023",
> "listen,accept,connect,resolve";
>  permission java.net.SocketPermission "localhost:8473",
> "listen,accept,connect,resolve";
>
> //permissions to files used in the application
>  permission java.io.FilePermission "/java/sysmon_test/-",
> "read,write,delete";
>  permission java.io.FilePermission "/127.0.0.1/ftp/-", "read, execute";
>
>
> // The IFSFILE access errors stops once the above were in the policy
> file
>
> // permission to each client computer
>  permission java.net.SocketPermission "Client computer domain:1024-",
> "accept,resolve";
>
> };
>
>
> -----Original Message-----
> From: java400-l-bounces@xxxxxxxxxxxx
> [mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of Peter Dow
> Sent: Thursday, June 25, 2009 12:33 PM
> To: Java Programming on and around the iSeries / AS400
> Subject: Re: Need help with SecurityManager and errors thrown by JT400
> classIFSFile
>
> Hi Charles,
>
> I'm kind of ignorant in this area, but isn't it possible to have a
> timeout when listening on a port, like you can with a data queue?  Then
> the program could listen to 1 port for say 500ms, and if nothing
> arrived, listen on the other port for 500ms, etc.
>
> *Peter Dow* /
> Dow Software Services, Inc.
> 909 793-9050
> pdow@xxxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxxx> /
>
> Charles Wilt wrote:
> > On Wed, Jun 24, 2009 at 5:34 PM, Blalock, Bill
> <Bill.Blalock@xxxxxxxx>wrote:
> > > My thought was to use security manager to
> > >
> > > -        allow it to listen only on port 3111
> > >
> > > -        allow it only to accept connections from a list of desktop
> > > client names in the policy file
> >
> >
> > Bill,
> >
> > Not familiar with Security manager, but thought I'd point out that an
> > applications (thread) can only listen on specific one port regardless.
> >
> > If you wanted an application to listen on two ports, for instance one
> > unsecured and one secured like http does, you'd have to have two
> separate
> > threads running; each listening to a specific port.
> >
> > Charles
> --
> This is the Java Programming on and around the iSeries / AS400
> (JAVA400-L) mailing list
> To post a message email: JAVA400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/java400-l
> or email: JAVA400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/java400-l.
>
> _____________
>
> The information contained in this message is proprietary and/or
> confidential. If you are not the
> intended recipient, please: (i) delete the message and all copies; (ii) do
> not disclose,
> distribute or use the message in any manner; and (iii) notify the sender
> immediately. In addition,
> please be aware that any message addressed to our domain is subject to
> archiving and review by
> persons other than the intended recipient. Thank you.
> _____________
> --
> This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
> mailing list
> To post a message email: JAVA400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/java400-l
> or email: JAVA400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/java400-l.