Win a copy of Fixing your Scrum this week in the Agile forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Rob Spoor
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Junilu Lacar
  • Tim Cooke
Saloon Keepers:
  • Tim Holloway
  • Piet Souris
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Frits Walraven
  • Himai Minh

admin port

 
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

Our security group recommended to make a small modification (among others) in jForum, which forces admin users to use a specific port to access jForum Admin Panel. This port will be opened for intranet users only (not to the web), which will reduce the chance that hackers from web get into the admin pages. You can find related jira here: http://www.jforum.net/jira/browse/JF-445

This feature is turned on ONLY if you add a variable to your jforum-custom.conf like:
admin.port = 5678
If admin.port is not found, jForum operates normally.

I implemented this feature, and attached to this message, as I couldn't see any way to attach files to jira record. I got the latest files from CVS before updating.

Hope it is OK, and can be added to CVS. Thanks...

15.12.05 Deleted JForum.java. See below for the updated version. This one was downloaded 32 times.
[originally posted on jforum.net by cagin]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Another option, which might be complementary, would be to use an IP filter over all the admin panel operations.

I'm curious about this change. Do you mean that now you would have JForum available through port 5678 apart of port 80? That means modifying also the servlet container configuration right?
Given that this would be directed towards security concerned groups, those groups usually will have control also over the container so I don't think that would be a problem.

Sounds useful.
[originally posted on jforum.net by GreenEyed]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Do you mean that now you would have JForum available through port 5678 apart of port 80?

Yes. If you want to access Admin Control Panel, you will have to type www.yourdomain.com:5678/forum.

That means modifying also the servlet container configuration right?

Yes, only once the application is setup in the server.
[originally posted on jforum.net by cagin]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Very insteresting!! I'll merge it to the head

Rafael
[originally posted on jforum.net by Rafael Steil]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

cagin wrote:Hi all,

Our security group recommended to make a small modification (among others) in jForum, which forces admin users to use a specific port to access jForum Admin Panel. This port will be opened for intranet users only (not to the web), which will reduce the chance that hackers from web get into the admin pages. You can find related jira here: http://www.jforum.net/jira/browse/JF-445
...



Your security group does not have a taste. Suggested feature (admin port) solve no problem actually REDUCING security in common setup.

1. Why it is reducing security - to implement this you typically need to pierce firewall. What often give more risk than help.

2. Why this feature is worthless: admin access to jforum is as important as some "key" user access. Especially moderators of most popular discussions. If one of moderator account is compromised - you at at same risk as admin account. The point is: protecting JUST admin account adds nothing to security. You need to protect ALL important users.

If one want some kind of protection - this should be done on user account level based on public key or, poor man protection, IP networks/IP address. Another suggestion of GreenEyed above about from source IP management is much more reasonable.
And to implement it you just need to extend IP filter of user accounts:
In addition to "Banned IPs" add a field "Allowd IP".

Rafael, I would strongly recommend to revert this wortless "admin port" feature and extend user IP filter instead. Also add an option to user account like "only https:// access is permitter"
[originally posted on jforum.net by Anonymous]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well,

Cagin suggested only the intranet users to have access to the administrator panel, so I don't see the need to pierce the firewall as outside users would not be able to access that port.

I have not played much with the admin and moderator panel, but I would guess the admin panel has access to more sensitive information, than the moderator one, so even though one could argue that the security is not complete, I would say that restricting access to the admin panel is at least, something. There would probably be less admin users than moderators, so I guess having all admins inside the intranet is reasonable, if you have to include moderators then you probably need to "pierce" your firewall, hence your problems.

If one is concerned with security, I agree with you that at least HTTPS needs to be used. Restricting admin users also, be it through a restricted port, restricted IPs or both. Moderators... it depends as I'm not sure what they are allowed to do.

In any case, there's absolutely nothing preveting you from explaining your point of view in a polite way and there's no need to be rude to others.


[originally posted on jforum.net by GreenEyed]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Anonymous wrote:Rafael, I would strongly recommend to revert this wortless "admin port" feature



Well, I hope this guy is not upset to me as much as he sounds :roll:

This feature is OPTIONAL, so if you don't like it, don't do anything; it wont affect anything.

Have fun...
[originally posted on jforum.net by cagin]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, it may increase security, although it's a very advanced feature. I will include it beucase its use is optional and not very intrusive.

Rafael
[originally posted on jforum.net by Rafael Steil]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Rafael Steil wrote:Well, it may increase security, although it's a very advanced feature. I will include it beucase its use is optional and not very intrusive.

Rafael



This feature increase nothing.
This is wrong feature done on wrong level by wrong people (with no taste).
No security checks should be done on URL or parameter matching level.
All security checks are done on action level.

In this (mis)feature implementation the guy uses URL matching check.
He protects agains URL with 'adm' in URL path. Like this.
http://localhost:8080/jforum_original/admBase/login.page
OK, take URL of search action and replace module=search to module=admBase
http://localhost:8080/jforum_original/jforum.page?module=admBase&action=search&clean=1&search_keywords=&search_terms=all&search_forum=&sort_by=time&sort_dir=DESC&search_cat=

You get same action executed, but this guy's check is not triggered.

I was critisized before for being rude, but nevetherless I would repeat:
This guy who suggested and implemented this feature has no taste.

The feature is wrong, implemented on wrong level by wrong people. Not to mention it does not work at all (see URL above) because of a bug. (This is the bug I noticed, the main problem with such (mis)features is that they intoduce a lot of hard to spot bugs).

An alternative may be IP checks (banned IP/allowed IP) implemented in login action module for ALL users. (Note that you have several login modules: segular, sso, other, so this feature is login module dependent).



[originally posted on jforum.net by Anonymous]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok, relax. The ?module=admBase&action=xxx in fact bypass the check by url string, so the code should be refactored to check the module / action name. This ends with all url discussion.

But anyway, as there are many discordances about that, the code will not be put on JForum.java - anyone who wants to check the url string to do such restrictions is suggested to create a ServletFilter.

Rafael
[originally posted on jforum.net by Rafael Steil]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A nitpick, not related to the subject of the duscussion, just a general opinion about input parameters matching security.

Rafael Steil wrote:so the code should be refactored to check the module / action name.



In this specific admin action case this will probably work (bacuse there is no much is done with admin actions), but in general case it may not work because there is often "action replace" in the code. One module/action just calls another module/action as java method. So in general case for input parameters bases security one potentialy need to audit all the java-paths to the specific module/action. There may be more than one java-path there, and while the code evolves - it is very hard to audit such things.

And this is the reason why URL -based security works only for plain .html files - because there is only one path to the file.
If you have something more complex than that - you need to implement any security on action level. In this case you know for sure that the action will not be executed.

(This is a general statement, not related to the discussion)
[originally posted on jforum.net by Anonymous]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Topic has become very interesting, thanks

I have no idea of how to make action level security. Our forum has no authentication method other than jforum default: Simple username-password control.

What about checking session if the user is admin? Pls see attached code which does this. Thanks again.
[originally posted on jforum.net by cagin]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A servlet filter looks the best approach, if you want to use this URL pattern stuff. It also prevents you of changing JForum's core code, keeping it easier to upgrade to newer versions

Rafael
[originally posted on jforum.net by Rafael Steil]
 
Not looking good. I think this might be the end. Wait! Is that a tiny ad?
the value of filler advertising in 2021
https://coderanch.com/t/730886/filler-advertising
reply
    Bookmark Topic Watch Topic
  • New Topic