Mar 14, 2022
05:09 PM
Can you provide more clarity on why some of those hosts are required? For example, hibernate.sourceforge.net redirects to hibernate.org when accessed via a web browser, and their web page suggests they use Github, not SourceForge?
... View more
Feb 27, 2022
03:42 PM
Hi @mrathinam , it's now the end of February and I haven't heard anything on this yet. Has any progress been made on determining how strict a firewall can be on an FNO site?
... View more
Jan 26, 2022
04:03 PM
So, over on Re: Flexera’s response to Apache Log4j vulnerabilities CVE-2021-4104, CVE-2021-45046, CVE-2021-45105 and CVE-2021-44228 Flexera say that they are "... reviewing and testing firewall configurations ..." Is Revenera doing the same testing? (Obviously, this is just my way of repeating my previous question - apologies)
... View more
Jan 09, 2022
11:37 PM
We blocked everything, except: - SMTP (so emails could get out) - Flexera themselves, so the FNO product licensing checks could be made Port 8888 is for INCOMING http requests and we left it as incoming only, nothing allowed out. Doing this allowed license activation, etc to function correctly but we found that it blocked entitlement creation for some reason. We do have incoming RDP allowed, but only from our internal network so anytime we need to get new software onto it, we need to retrieve it from the internet somewhere else and then PUSH it onto the server via the very controlled RDP. It's a pain not being able to Google directly from the FNO, but that's the price you pay for proper isolation. I am suspicious that "Create Entitlement" must be doing an out-bound request via port 8888 and that is not being done using 'localhost' but rather the fqdn of the server, which results in a full out-of-machine request, rather than looping back internally and thus the severe firewall blocks it - ie, the TCP/IP stack doesn't short-circuit the connection to stay inside the same VM. If this is the case, that's fine and I can get the network security types to allow the machine to "outbound connect to itself", I believe. But I want to double-check that this is actually what I require. It's all about having to justify on paper every security exception we make. And the fact that incoming activation works fine, but new entitlement doesn't is just a bit to squirrely for my liking...
... View more
Jan 09, 2022
07:59 PM
While it's good to see that FNO 2021 has been updated, those of us stuck on FNO 2018 (due to our use of Oracle as our storage) will need to continue to have the mitigations in place (removing the JNDI class completely). Is there any further word on exactly what the minimum external internet access is for an FNO to operate? ie, our experience was that blocking *everything* prevented the creation of new entitlements, so we have opened more ports than my security team are completely comfortable with...
... View more
Dec 20, 2021
08:34 PM
We have applied the deletion mitigation and found that our server is still functional, so thank you. One issue that arose during the fixups related to our blocking of all outgoing connections from that server. Incoming activation requests seemed to work fine, but attempting to create a new entitlement resulted in an application failure, which the logs reported as a connection timeout (that later resulted in another exception relating to an inability to close a transaction. Are there any additional requirements on network connectivity that are known for an FNO host? At the moment, we know that you need - to be able to verify our license of the FNO software - to be able to contact our SMTP server Is it also necessary to be able to connect out to any other external host? Or even the current host by IP address rather than loopback (127.0.0.1)? Our blocking was done in a VM host outside the FNO server itself in an attempt to ensure it was complete. I am suspicious, from looking at the trace, that it may have been doing something like looking up an XSD from somewhere? at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:1.8.0_102] at java.lang.Thread.run(Thread.java:745) [?:1.8.0_102] Caused by: java.net.ConnectException: Connection timed out: connect at java.net.TwoStacksPlainSocketImpl.socketConnect(Native Method) ~[?:1.8.0_102] at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) ~[?:1.8.0_102] at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) ~[?:1.8.0_102] at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) ~[?:1.8.0_102] at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172) ~[?:1.8.0_102] at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) ~[?:1.8.0_102] at java.net.Socket.connect(Socket.java:589) ~[?:1.8.0_102] at java.net.Socket.connect(Socket.java:538) ~[?:1.8.0_102] at sun.net.NetworkClient.doConnect(NetworkClient.java:180) ~[?:?] at sun.net.www.http.HttpClient.openServer(HttpClient.java:432) ~[?:?] at sun.net.www.http.HttpClient.openServer(HttpClient.java:527) ~[?:?] at sun.net.www.http.HttpClient.<init>(HttpClient.java:211) ~[?:?] at sun.net.www.http.HttpClient.New(HttpClient.java:308) ~[?:?] at sun.net.www.http.HttpClient.New(HttpClient.java:326) ~[?:?] at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1169) ~[?:?] at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1105) ~[?:?] at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:999) ~[?:?] at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:933) ~[?:?] at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1513) ~[?:?] at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441) ~[?:?] at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source) ~[xercesImpl-2.11.0.jar:?] at org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown Source) ~[xercesImpl-2.11.0.jar:?] at org.apache.xerces.impl.XMLEntityManager.startDTDEntity(Unknown Source) ~[xercesImpl-2.11.0.jar:?] at org.apache.xerces.impl.XMLDTDScannerImpl.setInputSource(Unknown Source) ~[xercesImpl-2.11.0.jar:?] at org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(Unknown Source) ~[xercesImpl-2.11.0.jar:?] at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) ~[xercesImpl-2.11.0.jar:?] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) ~[xercesImpl-2.11.0.jar:?] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) ~[xercesImpl-2.11.0.jar:?] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) ~[xercesImpl-2.11.0.jar:?] at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) ~[xercesImpl-2.11.0.jar:?] at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) ~[xercesImpl-2.11.0.jar:?] at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source) ~[xercesImpl-2.11.0.jar:?] at com.opensymphony.xwork2.util.DomHelper.parse(DomHelper.java:118) ~[struts2-core-2.5.17.jar:2.5.17]
... View more
Dec 20, 2021
08:23 PM
1 Kudo
Thanks @jholcomb On our 2018R1 server, I found the following candidates: c:\app>dir/s/b log4j*.xml c:\app\FlexNetOperations\components\tomcat\webapps\flexnetsetup\WEB-INF\classes\log4j.xml c:\app\FlexNetOperations\components\wildfly\modules\system\layers\base\com\flexnet\log4j\main\log4j2.xml c:\app\FlexNetOperations\components\wildfly\standalone\deployments\flexnet.ear\flexnet.war\WEB-INF\classes\log4j2.xml c:\app\FlexNetOperations\components\wildfly\standalone\tmp\vfs\temp\tempebc2bb9933e7168d\lfs.war-93bcb86ee815389e\WEB-INF\classes\lo g4j-default.xml c:\app\FlexNetOperations\components\wildfly\standalone\tmp\vfs\temp\tempebc2bb9933e7168d\lfs.war-93bcb86ee815389e\WEB-INF\classes\lo g4j.xml c:\app\FlexNetOperations\release\flexnet.ear\flexnet.war\WEB-INF\classes\log4j2.xml c:\app\FlexNetOperations\release\jbossConfig\flexnet\log4j\main\log4j2.xml c:\app\FlexNetOperations\webapp\WEB-INF\classes\log4j2.xml some of which are not PatternLayout definitions. ---------- C:\APP\FLEXNETOPERATIONS\COMPONENTS\TOMCAT\WEBAPPS\FLEXNETSETUP\WEB-INF\CLASSES\LOG4J.XML <param name="ConversionPattern" value="%d{ISO8601} %-5p [%c{2}] [%t] %m%n" /> but which look they may need similar attention - I would take a good look at pretty much any .xml file that contains "%m"
... View more
Dec 19, 2021
06:18 PM
1 Kudo
@jholcomb Did you do a full re-deploy of the software, or just hit all the .jar files in-situ? We only blocked outgoing connections from our license server so incoming activation requests still work fine - our customers should not be affected. Since the exploits all rely on external access, this seemed like a reasonable compromise - the only port we needed to open was SMTP which is still locked to a fixed server that we control.
... View more
Dec 19, 2021
03:34 PM
1 Kudo
@jholcomb can I ask what you mean by "applied log42.16" ? On our machine (which uses a local Oracle instance as well), I saw these: CC:\>dir/s/b log4j-core*.jar C:\...\components\wildfly\standalone\deployments\flexnet.ear\flexnet.war\WEB-INF\lib\log4j-core-2.8.2.jar C:\...\components\wildfly\standalone\tmp\vfs\deployment\deployment9f482d6c0bf06bb1\log4j-core-2.8.2.jar-52f20d693b caaa99\log4j-core-2.8.2.jar C:\...\release\flexnet.ear\flexnet.war\WEB-INF\lib\log4j-core-2.8.2.jar C:\...\webapp\WEB-INF\lib\log4j-core-2.8.2.jar C:\...\Oracle\...\12.2.0\dbhome_1\ccr\lib\log4j-core.jar C:\...\Oracle\...\12.2.0\dbhome_1\md\jlib\log4j-core-2.9.1.jar C:\...\Oracle\...\12.2.0\dbhome_1\oui\jlib\jlib\log4j-core.jar C:\...\Oracle\...\12.2.0\dbhome_1\sysman\jlib\ocm\log4j-core.jar C:\...\Oracle\...\PatchTop\27849056\27849056\files\md\jlib\log4j-core-2.9.1.jar Did you replace all instances of the 2.8.2 file with a 2.16 file, or just their contents? (ie, did your filenames remain the same? And did you need to do Oracle as well, or are you running a different database (or against a remote instance) At this point in time, I'm still leaning towards the "remove the JndiLookup.class from any .jar I find it in" approach
... View more
Dec 13, 2021
08:39 PM
@ChrisG Yes, the penny finally dropped that there are two pages here, both listing "FlexNet" products. When we purchased FNO, it was definitely from Flexera which is why I expected to see it listed here, not there.
... View more
Dec 13, 2021
07:14 PM
I don't see the FlexNet Operations Portal listed? Does that fall under some other product these days? (I realise that its an end-of-life product, but it's still being used)
... View more
Dec 12, 2021
08:42 PM
Our current mitigation strategy for this has been to put a complete block on ALL outgoing network access from our FNO server, with a specific exemption for SMTP access to our mail server. So, no http to google, no ntp, etc. Given that this is a single-purpose server, are there any other outgoing connections that an FNO server might need to have whitelisted?
... View more
Apr 07, 2019
05:37 PM
Why is lmgrd.exe sensitive? Until very recently (as I recall), anyone could download the latest version, there should be nothing specific in that binary to your private key.
... View more
Aug 14, 2011
09:18 PM
And, as always, all it takes is saying things out loud in public to trigger finding the problem. For those who care, the issue was that I had a 32-bit version of FnpCommsSoap.dll in the PATH - the 64-bit tool was finding it and failing whereas the 32-bit tool was fine. The appactutil tools weren't being tested with '-comms soap', just '-comms flexlm' In the SDK, that file is in the same directory as the executables. Ah well, at least I can serve as a bad example to others. Jeff.
... View more
Aug 14, 2011
08:53 PM
I have successfully built the 11.9 (and 11.10) FNP sdks including the standard activation utilities. All of the standard activation tools built into the SDK directory work fine. However, when I moved the sources to a different directory and rewrote the makefile to simplify it (as a start to building my own activation utility), I have hit a weird problem. The 32-bit versions of both appactutil and serveractutil work fine. The 64-bit version of appactutil works fine. The 64-bit version of serveractutil fails with bogus error messages. To be more precise, when you try to activate a server entitlement, you get an error from flxActSvrActivationSend(). I've seen the same thing in my own code, which is why I'm backtracking to building the standard tool (ie, eliminating my own code). Status: 4, Creating request Status: 5, Request created ERROR: flxActSvrActivationSend - (0,0,0) Although it fails, a major and minor error code of zero don't help diagnose the problem at all. The commands I'm using to build are: $(ARC_ROOT)\bin64\svract.exe:: $(SOURCES) $(MSDEV90)\bin\amd64\cl /nologo \ -DPC \ /c \ /I$(FNP64)/../machind \ /I$(FNP64)/.. \ /MT \ /O1 \ /DWINDOWS \ /I$(FNP64)/../machind/activation/include \ /I$(FNP64)/../machind/activation/include/windows \ /I$(MSDEV90)/include \ serverActUtil.c $(MSDEV90)\bin\amd64\link /nologo \ /NODEFAULTLIB \ /OPT:NOREF \ /NXCOMPAT \ /DynamicBase \ /OUT:$(ARC_ROOT)\bin64\svract.exe \ /LIBPATH:$(FNP64) \ /LIBPATH:$(FNP64)\activation\lib \ /LIBPATH:$(MSDEV90)\lib\amd64 \ /LIBPATH:$(MSDEV90)\platformsdk\lib\x64 \ serverActUtil.obj \ lm_new.obj \ lmgr.lib \ libsb.lib \ libcrvs.lib \ libact.lib \ libFNPload.lib \ oldnames.lib \ kernel32.lib \ user32.lib \ netapi32.lib \ advapi32.lib \ gdi32.lib \ comdlg32.lib \ comctl32.lib \ wsock32.lib \ Rpcrt4.lib \ oleaut32.lib \ Ole32.lib \ Wbemuuid.lib \ wintrust.lib \ crypt32.lib \ libcmt.lib \ lmgr_dongle_stub.lib which I believe is an exact transliteration of whats in the standard makefiles. FNP64 points to the ...\x64_n6\x64_n6. MSDEV90 point to the top of our VC9.0 SDK. ARC_ROOT is where we build our deliverables. I also run this through preptool appropriately as far as I can tell - I can include details there if appropriate. I am at my wits end here, I cannot see where the above differs in any way from the production sources, and yet there's works and mine doesn't. For what its worth, I've experienced the same problem with the 11.9IP4, the 11.10IP4 and the 11.10IP6 sdks. Does anyone have any clue what's going on here? Why would only the 64-bit server tool fail, when the 32-bit server tool works fine? I'm on 64-bit Windows 7, if that makes a difference... Jeff.
... View more
Labels
- Labels:
-
FlexNet Publisher
Latest posts by jefflaing
Subject | Views | Posted |
---|---|---|
291 | Mar 14, 2022 05:09 PM | |
1414 | Feb 27, 2022 03:42 PM | |
1719 | Jan 26, 2022 04:03 PM | |
1994 | Jan 09, 2022 11:37 PM | |
2003 | Jan 09, 2022 07:59 PM | |
2625 | Dec 20, 2021 08:34 PM | |
7516 | Dec 20, 2021 08:23 PM | |
8203 | Dec 19, 2021 06:18 PM | |
8230 | Dec 19, 2021 03:34 PM | |
38904 | Dec 13, 2021 08:39 PM |
Activity Feed
- Posted Re: Device not being created in FNO On prem 2018 R1 on FlexNet Operations Knowledge Base. Mar 14, 2022 05:09 PM
- Posted Re: CVE-2021-44228: Log4j vulnerability impact on FlexNet Operations On-Premises on FlexNet Operations Knowledge Base. Feb 27, 2022 03:42 PM
- Posted Re: CVE-2021-44228: Log4j vulnerability impact on FlexNet Operations On-Premises on FlexNet Operations Knowledge Base. Jan 26, 2022 04:03 PM
- Posted Re: CVE-2021-44228: Log4j vulnerability impact on FlexNet Operations On-Premises on FlexNet Operations Knowledge Base. Jan 09, 2022 11:37 PM
- Posted Re: CVE-2021-44228: Log4j vulnerability impact on FlexNet Operations On-Premises on FlexNet Operations Knowledge Base. Jan 09, 2022 07:59 PM
- Got a Kudo for Re: Security Advisory: Log4j Java Vulnerability (CVE-2021-4104, CVE-2021-45046, CVE-2021-44228). Dec 21, 2021 02:09 AM
- Posted Re: CVE-2021-44228: Log4j vulnerability impact on FlexNet Operations On-Premises on FlexNet Operations Knowledge Base. Dec 20, 2021 08:34 PM
- Posted Re: Security Advisory: Log4j Java Vulnerability (CVE-2021-4104, CVE-2021-45046, CVE-2021-44228) on Revenera Company News. Dec 20, 2021 08:23 PM
- Got a Kudo for Re: Security Advisory: Log4j Java Vulnerability (CVE-2021-4104, CVE-2021-45046, CVE-2021-44228). Dec 20, 2021 04:01 AM
- Got a Kudo for Re: Security Advisory: Log4j Java Vulnerability (CVE-2021-4104, CVE-2021-45046, CVE-2021-44228). Dec 20, 2021 03:59 AM
- Posted Re: Security Advisory: Log4j Java Vulnerability (CVE-2021-4104, CVE-2021-45046, CVE-2021-44228) on Revenera Company News. Dec 19, 2021 06:18 PM
- Kudoed Re: Security Advisory: Log4j Java Vulnerability (CVE-2021-4104, CVE-2021-45046, CVE-2021-44228) for jholcomb. Dec 19, 2021 06:14 PM
- Kudoed Re: Security Advisory: Log4j Java Vulnerability (CVE-2021-4104, CVE-2021-45046, CVE-2021-44228) for jholcomb. Dec 19, 2021 03:35 PM
- Posted Re: Security Advisory: Log4j Java Vulnerability (CVE-2021-4104, CVE-2021-45046, CVE-2021-44228) on Revenera Company News. Dec 19, 2021 03:34 PM
- Posted Re: Flexera’s response to Apache Log4j 2 remote code execution vulnerability CVE-2021-44228 on Community Notices. Dec 13, 2021 08:39 PM
- Posted Re: Flexera’s response to Apache Log4j 2 remote code execution vulnerability CVE-2021-44228 on Community Notices. Dec 13, 2021 07:14 PM
- Kudoed Re: Security Advisory: Log4j Java Vulnerability (CVE-2021-44228) for pauli_tuominen. Dec 13, 2021 03:34 PM
- Posted Re: Security Advisory: Log4j Java Vulnerability (CVE-2021-44228) on Revenera Company News. Dec 12, 2021 08:42 PM
- Kudoed Re: Security Advisory: Log4j Java Vulnerability (CVE-2021-44228) for uzihabaz. Dec 12, 2021 08:38 PM
- Posted Re: lmcrypt security on FlexNet Publisher Forum. Apr 07, 2019 05:37 PM