The remote server's SSL certificate has already expired - Plugin ID 15901
Hi Experts We are running Nessus Scan against our F5 BIG-IP LTM devices and getting following alert:- The remote server's SSL certificate has already expired - Plugin ID 15901 Now problem is that we are using IP address to logon to these devices instead of a common name (CN) which is used by SSL certs. We can`t remove it for sure. Now how to regenerate it without a common name (CN) is a concern for us ? Some of the information from F5:- http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/tmos_management_guide_10_1/tmos_device_certif_config.html1019303 Here is our cert information:- General Properties Name server Certificate Subject(s) My Company Ltd Certificate Properties Expires Jan 16, 2013 Version 3 Serial Number XXXX Subject Common Name: Organization: My Company Ltd Division: Locality: Yes State Or Province: No Country: YO Issuer Self Any advice will be highly appreciated. Thanks
Block HTTP access from specific user agent(2)
Dear community, I want to arrange iRule which I learned in following URL. https://devcentral.f5.com/questions/block-https-access-from-specific-user-agentanswer118447 Can I use iRule like this? My client doesn't want to show even 404. when HTTP_REQUEST { log local0. "User-Agent:[HTTP::header "User-Agent"]" if { ([regexp sqlmap|havij|nmap|nessus|absinthe|nikto|w3af|pangolin|bsqlbf|prog.customcrawler|sql\ power\ injector|mysqloit|netsparker [string tolower [HTTP::header "User-Agent"]]]) && !([IP::addr [IP::client_addr] equals 192.168.115.100]) } { discard log local0. "[HTTP::header "User-Agent"] discarding." } }The remote service supports the use of week/medium strength SSL ciphers - Plugin ID (26928/42873)
Hi There We are running Nessus Scan for BIG-IP LTM devices and getting following Alerts :- The remote service supports the use of medium strength SSL ciphers - Plugin ID (26928) The remote service supports the use of weak SSL ciphers. - Plugin ID (42873) Description: The remote host supports the use of SSL ciphers that offer medium strength encryption, which we currently regard as those with key lengths at least 56 bits and less than 112 bits. Note: This is considerably easier to exploit if the attacker is on the same physical network. Solution: Reconfigure the affected application if possible to avoid use of medium strength ciphers. Basically these alerts only indicating Admin IP and the alert so we assume these alerts are related with the admin interface where low/medium end ciphers needs to be disabled. This was our initial cipher strength HTTPD - SSLCipherSuite: ALL:!ADH:!EXPORT56:!eNULL:!MD5:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP In the configuration, We have disabled low cypher i.e HTTPD -SSLCipherSuite ALL:!ADH:!SSLv2:!EXPORT40:!EXP:!LOW This disabling all the cipher length less than 128 bits length. http://support.f5.com/kb/en-us/solutions/public/7000/800/sol7815.html Even after aplying the fix, we are getting these alerts. Can anyone advice what is the possible solution/fix here ? Can we take them as false positive and close the alerts ? Thanks in advance !!
Configure X-forwarded-for on WebSphere App server
Hi, I need to use X-forwarded-for to print data from the client that hit the load balance in WebSphere app server. My architecture as follows: 5 app server connect to --- F5 ---- directed request to 2 app server Can I use X-forwarded-for to print these data directly from F5 to the app servers SystemOut since I do not use HTTP servers? Regards,
Can't open java applet component when connecting to the application through Load balancer F5
Hi We have one new building and the workstations are connected to our network. There is two systems that has java applet components that when clicked, it does not load the java applet. But when connecting to the application server node directly, these java applet components are opened. Al other buildings in other locations are working fine even through the current F5. Only this site has the issue !!! Our collegues checked for the workstation configurations and also bring one workstation to our IT department building and connected to same applications through the same F5, it Worked without any issues. I have one system for Oracle applications 12.1 that I enabled the java debugging console. The output showed exception network: Connecting http://hrms.domain.org:8080/ with proxy=DIRECT java.lang.InterruptedException at java.lang.Object.wait(Native Method) at sun.plugin2.message.Queue.waitForMessage(Unknown Source) at sun.plugin2.message.Pipe.receive(Unknown Source) at sun.plugin2.main.client.MessagePassingExecutionContext.doCookieOp(Unknown Source) at sun.plugin2.main.client.MessagePassingExecutionContext.getCookie(Unknown Source) at sun.plugin2.main.client.PluginCookieSelector.getCookieFromBrowser(Unknown Source) at com.sun.deploy.net.cookie.DeployCookieSelector.getCookieInfo(Unknown Source) at com.sun.deploy.net.cookie.DeployCookieSelector.get(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.setCookieHeader(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.writeRequests(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) at com.sun.deploy.net.DownloadEngine.getJarFileWithoutCache(Unknown Source) at com.sun.deploy.net.DownloadEngine.downloadJarWithoutCache(Unknown Source) at sun.plugin.PluginURLJarFileCallBack$2.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.plugin.PluginURLJarFileCallBack.retrieve(Unknown Source) at sun.net.www.protocol.jar.URLJarFile.retrieve(Unknown Source) at sun.net.www.protocol.jar.URLJarFile.getJarFile(Unknown Source) at sun.net.www.protocol.jar.JarFileFactory.get(Unknown Source) at sun.net.www.protocol.jar.JarURLConnection.connect(Unknown Source) at sun.plugin.net.protocol.jar.CachedJarURLConnection.connect(Unknown Source) at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFileInternal(Unknown Source) at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFile(Unknown Source) at com.sun.deploy.security.DeployURLClassPath$JarLoader.getJarFile(Unknown Source) at com.sun.deploy.security.DeployURLClassPath$JarLoader.access$1000(Unknown Source) at com.sun.deploy.security.DeployURLClassPath$JarLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at com.sun.deploy.security.DeployURLClassPath$JarLoader.ensureOpen(Unknown Source) at com.sun.deploy.security.DeployURLClassPath$JarLoader.(Unknown Source) at com.sun.deploy.security.DeployURLClassPath$3.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source) at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source) at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source) at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source) at sun.plugin2.applet.Plugin2Manager.createApplet(Unknown Source) at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source) at java.lang.Thread.run(Unknown Source) network: Cookie service is not available - use cache to determine "Cookie" network: Connecting http://hrms.domain.org:8080/OA_JAVA/oracle/apps/fnd/jar/fndewt.jar with cookie "HRPROD=rClRylxIBeH_r2yj3qbDh_n8:S; BIGipServerPool-NDC-HRMS-8080=269161644.16415.0000; oracle.uix=0^^GMT+3:00^p" network: Downloading resource: http://hrms.domain.org:8080/OA_JAVA/oracle/apps/fnd/jar/fndewt.jar Content-Length: 2,241,848 Content-Encoding: null We are using BIG-IP 11.0.0 Build 8037.0 Final The issue only happen for that building, all other buildings connecting the same F5 are working fine without any issues. When opening the page directly from the application server, like http://node1.domain.org:8080 , the java applet is downloadable and can be displayed. Kindly advice Thank you C.
Combine Client accepted and http_request.
I have an requirement to forward a source IP to particular pool member. Since I already have http_request configured is it a good idea to add client_accepted into the same irule ? when HTTP_REQUEST { if { [HTTP::host] == "my fqdn" } { HTTP::redirect "https://myfqdn/irj/portal/" pool pool_t_portal } if { [HTTP::uri] equals "/" or [HTTP::uri] equals "/index.html" or [HTTP::uri] equals "/webdynpro/welcome/Welcome.jsp" } { HTTP::redirect "https://[HTTP::host]/irj/portal/" } if { [HTTP::uri] starts_with "/~" and [HTTP::uri] ends_with "index.html"} { HTTP::redirect "https://[HTTP::host]/irj/portal/" } if { [HTTP::uri] starts_with "/uddiclient" or [HTTP::uri] equals "/uddiclient/process"} { HTTP::redirect "https://[HTTP::host]/irj/portal/" } if { [HTTP::uri] equals "/nwa" } { HTTP::redirect "https://[HTTP::host]/irj/portal/" } } when CLIENT_ACCEPTED { if {[IP::addr [IP::client_addr] equals "src.src.src.src"]}{ pool "pool_q_portal" member dst.dst.dst.dst} }
Websphere Portal and webmaster access error
Dear all I had Virtual Server 172.16.80.72 with pool 3 APP Webshpere 172.16.85.71:10039,172.16.85.72:10050, 172.16.85.73:10050. VS's irule redirect from http://172.16.80.72 to http://172.16.80.72/wcs/portal. After configuration, client access it well but webmaster has few complaints. After login to admin website, admin interface broken icons. When click the tab for system administrator, error message display "Google chrome could not connect http://172.16.80.72:10050/wcs/myportal". I want to use VS replace the edge server 172.16.80.32. If click the tab for system administrator on 172.16.80.32, access link is http://172.16.80.32/wcs/myportal. How to resolve problem ? I need config on F5 or request webmaster config for http response from server app to F5 auto change the service port from 10050 to 80. Best Regard
Quick! The Data Center Just Burned Down, What Do You Do?
You get the call at 2am. The data center is on fire, and while the server room itself was protected with your high-tech fire-fighting gear, the rest of the building billowed out smoke and noxious gasses that have contaminated your servers. Unless you have a sealed server room, this is a very real possibility. Another possibility is that the fire department had to spew a ton of liquid on your building to keep the fire from spreading. No sealed room means your servers might have taken a bath. And sealed rooms are a real rarity in datacenter design for a whole host of reasons starting with cost. So you turn to your DR plan, and step one is to make certain the load was shifted to an alternate location. That will buy you time to assess the damage. Little do you know that while a good start, that’s probably not enough of a plan to get you back to normal quickly. It still makes me wonder when you talk to people about disaster recovery how different IT shops have different views of what’s necessary to recover from a disaster. The reason it makes me wonder is because few of them actually have a Disaster Recovery Plan. They have a “Pain Alleviation Plan”. This may be sufficient, depending upon the nature of your organization, but it may not be. You are going to need buildings, servers, infrastructure, and the knowledge to put everything back together – even that system that ran for ten years after the team that implemented it moved on to a new job. Because it wouldn’t still be running on Netware/Windows NT/OS2 if it wasn’t critical and expensive to replace. If you’re like most of us, you moved that system to a VM if at all possible years ago, but you’ll still have to get it plugged into a network it can work on, and your wires? They’re all suspect. The plan to restore your ADS can be painful in-and-of itself, let alone applying the different security settings to things like NAS and SAN devices, since they have different settings for different LUNS or even folders and files. The massive amount of planning required to truly restore normal function of your systems is daunting to most organizations, and there are some question marks that just can’t be answered today for a disaster that might happen in a year or even ten – hopefully never, but we do disaster planning so that we’re prepared if it does, so never isn’t a good outlook while planning for the worst. While still at Network Computing, I looked at some great DR plans ranging from “send us VMs and we’ll ship you servers ready to rock the same day your disaster happens” to “We’ll drive a truck full of servers to your location and you can load them up with whatever you need and use our satellite connection to connect to the world”. Problem is that both of these require money from you every month while providing benefit only if you actually have a disaster. Insurance is a good thing, but increasing IT overhead is risky business. When budget time comes, the temptation to stop paying each month for something not immediately forwarding business needs is palpable. And both of those solutions miss the ever-growing infrastructure part. Could you replace your BIG-IPs (or other ADC gear) tomorrow? You could get new ones from F5 pretty quickly, but do you have their configurations backed up so you can restore? How about the dozens of other network devices, NAS and SAN boxes, network architecture? Yeah, it’s going to be a lot of work. But it is manageable. There is going to be a huge time investment, but it’s disaster recovery, the time investment is in response to an emergency. Even so, adequate planning can cut down the time you have to invest to return to business-as-usual. Sometimes by huge amounts. Not having a plan is akin to setting the price for a product before you know what it costs to produce – you’ll regret it. What do you need? Well if you’re lucky, you have more than one datacenter, and all you need to do is slightly oversize them to make sure you can pick up the slack if one goes down. If you’re not one of the lucky organizations, you’ll need a plan for getting a building with sufficient power, internet capability, and space, replace everything from power connections to racks to SAN and NAS boxes, restorable backups (seriously, test your backups or replication targets. There are horror stories…), and time for your staff to turn all of these raw elements into a functional datacenter. It’s a tall order, you need backups of the configs of all appliances and information from all of your vendors about replacement timelines. But should you ever need this plan, it is far better to have done some research than to wake up in the middle of the night and then, while you are down, spend time figuring it all out. The toughest bit is keeping it up to date, because a project to implement a DR plan is a discrete project, but updating costs for space and lists of vendors and gear on a regular basis is more drudgery and outside of project timelines. But it’s worth the effort as insurance. And if your timeline is critical, look into one of those semi trailers – or the new thing (since 2005 or 2007 at least), containerized data centers - because when you need them, you need them. If you can’t afford to be down for more than a day or two, they’re a good stopgap while you rebuild. SecurityProcedure.com has an aggregated list of free DR plans online. I’ve looked at a couple of the plans they list, they’re not horrible, but make certain you customize them to your organization’s needs. No generic plan is complete for your needs, so make certain you cover all of your bases if you use one of these. The key is to have a plan that dissects all the needs post-disaster. I’ve been through a disaster (The Great NWC Lab Flood), and there are always surprises, but having a plan to minimize them is a first step to maintaining your sanity and restoring your datacenter to full function. In the future – the not-too-distant future – you will likely have the cloud as a backup, assuming that you have a product like our GTM to enable cloud-bursting, and that Global Load Balancer isn’t taken out by the fire. But even if it is, replacing one device to get your entire datacenter emulated in the cloud would not be anywhere near as painful as the rush to reassemble physical equipment. Marketing Image of an IBM/APC Container Lori and I? No, we have backups and insurance and that’s about it. But though our network is complex, we don’t have any businesses hosted on it, so this is perfectly acceptable for our needs. No containerized data centers for us. Let’s hope we, and you, never need any of this.
