I am trying to write modsecurity rule exclusions and cant seem to get ctl:ruleRemoveTargetById to work as per the reference manual.
My server is running Debian 9 with apache2 2.4.25-3+deb9 I have tried following the reference manual on github and tried emulating the sample rules in the file >REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf. I have written a simple rule to fire on certain arguments and then tried excluding it, but it wont exclude the rule based on the arguments. I can see both the rule id and the rule exclusion id in the logs.
I have, arbitrarily, put the below rule in REQUEST-905-COMMON-EXCEPTIONS.conf
SecRule ARGS "#rx propfind" "id:905999,phase:2,log,msg:'test msg delete rule'"
This fires as it should. There is an argument named <?xml version that contains the pattern "propfind" in my nextcloud settings page, which I am using for testing.
I have also written an exclusion and put it into REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
SecRule ARGS_NAMES "#rx <\?xml\sversion" "phase:2,log,id:1030,ctl:ruleRemoveTargetById=905999;ARGS:/<\?xml\sversion/"
This rule triggers as expected but does not prevent rule 905999 from firing on argument named <?xml version
I have simplified the rules to the two below and it works as expected; when I enter example.com/?test=trigger I see rule 905999 in the log, but if I send example.com/?testarg=trigger I only see the exclusion rule 1030 as expected.
SecRule ARGS "#rx trigger" "id:905999,phase:2,log,msg:'test msg delete rule'"
SecRule ARGS_NAMES "#rx testarg" "phase:2,log,id:1030,ctl:ruleRemoveTargetById=905999;ARGS:testarg"
When I open the nextcloud settings tab the HTTP request contains
<?xml version="1.0"?><d:propfind xmlns:d="DAV:"><d:prop><d:resourcetype/></d:prop></d:propfind>
which Modsec interprets as the argument name <?xml version, containing the value "1.0"?><d:propfind xmlns:d="DAV:"><d:prop><d:resourcetype/></d:prop></d:propfind>
I would expect my rule 1030 to stop 905999 from firing, but i still see both rules in the log. I am assuming it is because of the space between "xml" and "version" but cant figure out how to exclude the target.
For some reason the regex in ctl:ruleRemoveTargetById=905999;ARGS:/<\?xml\sversion/ did not work. Using SecRuleUpdateTargetById 905999 "!ARGS:/<\?xml\sversion" and placing it into RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf to update the rule targets after they are loaded works as desired.
We changed the configuration of our WebLogic servers to use HTTPS and T3S for connections and use the secure encrypted port 9002 instead of cleartext port 7001. However when using the Web Logic Scripting Tool (WLST)'s connect() function, errors are thrown. One such error is as follows:
WLSTException: Error occurred while performing connect : Cannot connect via t3s or https. If using demo certs, verify that the -Dweblogic.security.TrustKeyStore=DemoTrust system property is set. : t3s://DatServer:9002: Destination 10.10.100.3, 9002 unreachable; nested exception is:
javax.net.ssl.SSLHandshakeException: General SSLEngine problem; No available router to destination
Use dumpStack() to view the full stacktrace :
The syntax of the connect function is: connect('user', 'password', 't3s://host:9002')
This connect() function works fine before the switch from HTTP to HTTPS. Now we cannot connect to the remote admin server using the connect command. Does anyone have any idea how to fix this?
I read some interesting help options but none of them seemed to work. These help suggestions and tips are located here: https://community.oracle.com/thread/1036828
We were able to connect to the remote host and port via telnet. We saw that the port is open and listening for connections on the loop back address with netstat. We tried adding these options to the script invocation: java -cp /path/to/weblogic.jar weblogic.WLST -Dweblogic.security.TrustKeyStore=DemoTrust -Dssl.debug=true Dweblogic.security.SSL.ignoreHostnameVerification=true -Djava.security.egd=file:/dev/./urandom but this also did not work.
We enabled tunneling in the General tab of WebLogic but not in the HTTP tab. I am not the one in control of the server so I just have to suggest things and hope that the instructions are followed.
I get it running in 12.2. by adding to
../oracle_common/common/bin/setWlstEnv_internal.sh
at the end the following lines (youu need to customize line 5 und 6, the values in brackets):
JAVA_OPTIONS="-Dweblogic.ssl.JSSEEnabled=true ${JAVA_OPTIONS}"
JAVA_OPTIONS="-Dweblogic.security.SSL.enableJSSE="true" ${JAVA_OPTIONS}"
JAVA_OPTIONS="-Dweblogic.security.SSL.ignoreHostnameVerification=true ${JAVA_OPTIONS}"
JAVA_OPTIONS="-Dweblogic.security.TrustKeyStore=CustomTrust ${JAVA_OPTIONS}"
JAVA_OPTIONS="-Dweblogic.security.CustomTrustKeyStoreFileName= ${JAVA_OPTIONS}"
JAVA_OPTIONS="-Dweblogic.security.CustomTrustKeyStorePassPhrase= ${JAVA_OPTIONS}"
JAVA_OPTIONS="-Dweblogic.security.CustomTrustKeyStoreType=JKS ${JAVA_OPTIONS}"
export JAVA_OPTIONS
and modifying in
../oracle_common/common/bin/wlst_internal.sh
the line starting with
eval '"${JAVA_HOME}/bin/java"' ${JVM_ARGS} ...
by adding ${JAVA_OPTIONS}
so that it looks as follows:
eval '"${JAVA_HOME}/bin/java"' ${JVM_ARGS} ${JAVA_OPTIONS} weblogic.WLST '"$#"'
Hope this helps, allthough modifying scripts that are named "..internal.." doesn´t give me a good feeling
export this before running wlst.sh
export WLST_PROPERTIES=" -Dweblogic.security.TrustKeyStore=CustomTrust -Dweblogic.security.CustomTrustKeyStoreFileName=/u01/oracle/properties/truststore.jks -Dweblogic.security.CustomTrustKeyStoreType=jks -Dweblogic.security.CustomTrustKeyStorePassPhrase=qaz#1234 " ;
I have added a customized module named mod_confirm_delivery in ejabberd which has compiled and added successfully but when i am sending a message an error is coming in my ejabberd error log file, That is:
2016-03-15 17:03:38.306 [error] <0.2653.0>#ejabberd_hooks:run_fold1:368 {undef,[{mod_confirm_delivery,send_packet,[{xmlel,<<"iq">>,[{<<"xml:lang">>,<<"en">>},{<<"type">>,<<"get">>},{<<"id">>,<<"aacfa">>}],[{xmlcdata,<<"\n">>},{xmlel,<<"query">>,[{<<"xmlns">>,<<"jabber:iq:roster">>}],[]},{xmlcdata,<<"\n">>}]},{state,{socket_state,gen_tcp,#Port<0.58993>,<0.2652.0>},ejabberd_socket,#Ref<0.0.1.25301>,false,<<"12664578908237388886">>,undefined,c2s,c2s_shaper,false,false,false,false,[verify_none,compression_none],true,{jid,<<"test1">>,<<"localhost">>,<<"D-5">>,<<"test1">>,<<"localhost">>,<<"D-5">>},<<"test1">>,<<"localhost">>,<<"D-5">>,{{1458,41617,630679},<0.2653.0>},{2,{{<<"test2">>,<<"localhost">>,<<>>},{{<<"test1">>,<<"localhost">>,<<>>},nil,nil},nil}},{2,{{<<"test2">>,<<"localhost">>,<<>>},{{<<"test1">>,<<"localhost">>,<<>>},nil,nil},nil}},{0,nil},undefined,undefined,{userlist,none,[],false},c2s,ejabberd_auth_internal,{{127,0,0,1},41928},[],active,[],inactive,undefined,undefined,1000,undefined,300,300,false,0,0,true,<<"en">>},{jid,<<"test1">>,<<"localhost">>,<<"D-5">>,<<"test1">>,<<"localhost">>,<<"D-5">>},{jid,<<"test1">>,<<"localhost">>,<<>>,<<"test1">>,<<"localhost">>,<<>>}],[]},{ejabberd_hooks,safe_apply,3,[{file,"src/ejabberd_hooks.erl"},{line,382}]},{ejabberd_hooks,run_fold1,4,[{file,"src/ejabberd_hooks.erl"},{line,365}]},{ejabberd_c2s,session_established2,2,[{file,"src/ejabberd_c2s.erl"},{line,1268}]},{p1_fsm,handle_msg,10,[{file,"src/p1_fsm.erl"},{line,582}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,240}]}]}
I have ejabberd 16.02.26 and my module code is:
mod_confirm_delivery.erl
This module is working fine with ejabberd 2.1.13 but i want to upgraded my ejabberd. I can't understand what is the problem and how can I resolve this error.
undef error means the function or module is not found. The most likely error is that the mod_confirm_delivery.beam file is not in Erlang VM path.
You should try moving the compiled beam file with other ejabberd beam files or try setting the path used to launch Erlang to the directory where your mod_confirm_delivery.beam file is located. This is the -pa option of the Erlang VM.
If your code if in right place, other option is that the function is undefined. The hook tries to call mod_confirm_delivery:send_packet/4. Your code is wrong as it indeed does not defined send_packet/4 but only send_packet/3. You need to update your code to match new signature for user_send_packet hook:
user_send_packet(Packet, C2SState, From, To) -> Packet
In case of doubt, you can refer to official hook list in ejabberd documentation: https://docs.ejabberd.im/developer/hooks/
I did all that is specified in the tutorial - Doxygen Plugin.
Here is the sonarqube-4.5.1/conf/sonar.propeties file doxygen entries:
# Doxygen
sonar.doxygen.generateDocumentation=enable
sonar.doxygen.deploymentPath=D:\Downloads\sonarqube-4.5.1\web
sonar.doxygen.deploymentUrl=http://localhost:9000/sonar/documentation
The output of the sonarqube runner:
16:07:16.265 INFO - ANALYSIS SUCCESSFUL
16:07:16.266 DEBUG - Post-jobs : org.sonar.plugins.doxygen.DoxygenPostJob#28bda649
16:07:16.266 INFO - Executing post-job class org.sonar.plugins.doxygen.DoxygenPostJob
16:07:16.271 INFO - === SUPPRESS PREVIOUS GENERATION ===
16:07:16.395 INFO - === DOXYGEN EXECUTION ===
16:07:16.396 INFO - ### Generating configuration ###
16:07:16.427 INFO - ### Generating documentation ###
Also, in the specified \web folder there is a documentation folder which seems to contain the correct doxygen documentation output.
Yet I keep getting this Documentation Generation is disabled. message in the SonarQube web interface:
UPDATE
This is what my sonar-project.properties file contains now ― using a unix-style path:
#Doxygen
sonar.doxygen.generateDocumentation=enable
sonar.doxygen.deploymentPath=/Downloads/sonarqube-4.5.1/web
sonar.doxygen.deploymentUrl=http://localhost:9000/sonar/documentation
The output remains the same, same issue.
What do I need to do in order to see the documentation in the web server interface?
This seems to be a server linkage problem, because the documentation is being generated correctly, at this location: /Downloads/sonarqube-4.5.1/web/documentation.
I have also found this content:
core,true,sonar-core-plugin-4.5.1.jar|9289fc1067c31372c0b020aa01163087
emailnotifications,true,sonar-email-notifications-plugin-4.5.1.jar|bb35818e4a655a3ba2cff2afc65a296b
findbugs,false,sonar-findbugs-plugin-2.4.jar|bb0bf263ef1e0d56f569878732060cc9
java,false,sonar-java-plugin-2.4.jar|a105d018165ddeb2c0f5074100768660
cpd,true,sonar-cpd-plugin-4.5.1.jar|e11ff5066c9e2308036838510d87a6fe
dbcleaner,true,sonar-dbcleaner-plugin-4.5.1.jar|a444b3b4571791e1cde146ffa5132ee4
design,true,sonar-design-plugin-4.5.1.jar|0c6476994a44904307cfa8b8a08bbddd
doxygen,false,sonar-doxygen-plugin-0.1.jar|d86e1ab81c3ac34e6b31aa1da28d7f72
l10nen,true,sonar-l10n-en-plugin-4.5.1.jar|c21d53f67901cf6df3da1b4dd48a441b
in sonarqube-4.5.1\web\deploy\plugins\index.txt.
It looks like doxygen has a false associated with it. If I try to edit it (to true) and restart the server nothing changes. The file is overwritten at by the sonar-runner.
sonar.doxygen.generateDocumentation is a project property, not a server property. You have to set it in your "sonar-project.properties" file if you run your analysis with the SonarQube Runner or in your pom.xml file if you run the analysis with Maven.
Here is how I solved this:
Stopped the sonar-qube server.
Replaced the old sonar-doxygen-plugin-0.1.jar, from /Downloads/sonarqube-4.5.1/extensions/plugins, with the updated doxygen plugin from here https://github.com/SonarCommunity/sonar-doxygen/releases/download/1.0/sonar-doxygen-plugin-1.0-SNAPSHOT.jar.
Commented out the old configuration entries for doxygen from the project sonar-project.properties file. And replaced them with the follwoing entries:
sonar.doxygen.url=http://localhost:8000/
sonar.doxygen.enable=true
Used a simple python script to post the documentation html on that server (http://localhost:8000/).
Restarted the sonar-qube server.
Run the sonar-runner.bat again.
The documentation is in its place now.
I am getting the following warning in my code:
Warning: is_readable() [function.is-readable]: open_basedir restriction in effect. File(/usr/share/php/./views/helpers/Doctype.php) is not within the allowed path(s): (/var/www/virtual/example.com/:/usr/share/pear/) in /var/www/virtual/example.com/htdocs/rockhopper-v2/library/Zend/Loader.php on line 198
or
Warning: is_readable() [function.is-readable]: open_basedir restriction in effect. File(/usr/share/php//var/www/virtual/example.com/htdocs/rockhopper-v2/application/modules/default/views/helpers/Layout.php) is not within the allowed path(s): (/var/www/virtual/example.com/:/usr/share/pear/) in /var/www/virtual/example.com/htdocs/rockhopper-v2/library/Zend/Loader.php on line 198
what is the problem and will it cause problems in deployment and production stage of my application?
Thank you
This message appears because since Zend FW 1.10.1 the autoloader creates the path to those files differently. You can find some more information here: Zend FW Bug Report
To get rid of this message you can edit the file index.php and change the set_include_path to this:
set_include_path(
APPLICATION_PATH.'/../library'.PATH_SEPARATOR.
APPLICATION_PATH.'/../library/Zend'
);
open_basedir is set php is running in safe mode. It restricts you to the folders specified in the list. This might help: http://blog.php-security.org/archives/72-Open_basedir-confusion.html
And yes, you will need to change it on any server if you want to access files outside the default folder.