This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Accept
Reject
  • RSA.com
  • Home
  • Advisories
    • SecurID
    • SecurID Governance & Lifecycle
  • Documentation
    • SecurID
      • Authentication Agents
        • API / SDK
        • Apache Web Server
        • Citrix StoreFront
        • IIS Web Server
        • MFA Agent for macOS
        • MFA Agent for Windows
        • Microsoft AD FS
        • Microsoft Windows
        • PAM
      • Authentication Engine
      • Authentication Manager
      • Cloud Authentication Service
      • Hardware Appliance
        Component Updates
      • Hardware Tokens
      • Integrations
      • SecurID App
      • SecurID Authenticator for macOS
      • SecurID SDK
      • Software Tokens
        • Android
        • iOS
        • macOS
        • Token Converter
        • Windows
    • SecurID Governance & Lifecycle
    • Technology Partners
  • Downloads
    • SecurID
      • Authentication Agents
        • API / SDK
        • Apache Web Server
        • Citrix StoreFront
        • IIS Web Server
        • MFA Agent for macOS
        • MFA Agent for Windows
        • Microsoft AD FS
        • Microsoft Windows
        • PAM
      • Authentication Engine
      • Authentication Manager
      • Cloud Authentication Service
      • Hardware Appliance
        Component Updates
      • Hardware Tokens
      • Integrations
      • SecurID Authenticator for macOS
      • Software Tokens
        • Android
        • iOS
        • macOS
        • Token Converter
        • Windows
    • SecurID Governance & Lifecycle
  • Community
    • SecurID
      • Blog
      • Discussions
      • Events
      • Idea Exchange
      • Knowledge Base
    • SecurID Governance & Lifecycle
      • Blog
      • Discussions
      • Events
      • Idea Exchange
      • Knowledge Base
  • Support
    • Case Portal
      • Create New Case
      • View My Cases
      • View My Team's Cases
    • Community Support
      • Getting Started
      • News & Announcements
      • Ideas & Suggestions
      • Community Support Articles
      • Community Support Forum
    • Product Life Cycle
    • Support Information
    • General Security Advisories
  • Education
    • Blog
    • Browse Courses
      • SecurID
      • SecurID Governance & Lifecycle
    • Certification Program
    • New Product Readiness
    • Student Resources
Sign In Register Now
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
Announcements

SecurID® Discussions

Browse the SecurID discussion board to get product help and collaborate with other SecurID users.
  • SecurID Community
  • :
  • Products
  • :
  • SecurID
  • :
  • Discussions
  • :
  • Port TCP/7006 Between AM and WebTier
  • Options
    • Subscribe to RSS Feed
    • Mark Topic as New
    • Mark Topic as Read
    • Float this Topic for Current User
    • Bookmark
    • Subscribe
    • Mute
    • Printer Friendly Page
BadrHoussni
BadrHoussni Beginner
Beginner
‎2019-12-17 09:17 AM
  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Subscribe to RSS Feed
  • Permalink
  • Print
  • Email to a Friend
  • Report Inappropriate Content

Port TCP/7006 Between AM and WebTier

Jump to solution

Hi,
Can someone explain to me why our webtiers tries to contact our AM's on TCP/7006 ?

I can't find anywhere somehting related to this port.

Thank you.

AM : 8.4 P8

WT : GNU/Linux Red Hat

Labels (1)
Labels
  • Labels:
  • Agents

  • Tags:
  • 7006
  • Agent
  • Agents
  • Auth Agent
  • Authentication Agent
  • Community Thread
  • Discussion
  • Forum Thread
  • ports
  • RSA SecurID
  • RSA SecurID Access
  • SecurID
  • webtier
0 Likes
Share
Reply
  • All forum topics
  • Previous Topic
  • Next Topic
1 Solution

Accepted Solutions
EdwardDavis
Employee EdwardDavis
Employee
‎2019-12-17 09:34 AM
  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Subscribe to RSS Feed
  • Permalink
  • Print
  • Email to a Friend
  • Report Inappropriate Content

Jump to solution

Port 7006 is not needed and not used. But weblogic on the Primary AM server does log the attempts.

 

My 8.4.0.8.0 AM Primary system does have a log file indicating errors connecting to my webtier 10.101.99.162 on port 7006, but it doesn't need this...this must be some leftover in the code where weblogic is trying a full list of options, but we don't happen to need port 7006 to actually connect to a webtier. So, this error is really something to ignore...

 

From a log file in my AM Primary /opt/rsa/am/server/logs directory:

 

INFO | jvm 1 | main | 2019/10/17 11:03:24 | java.net.ConnectException: Tried all: 1 addresses,

but could not connect over HTTPS to server: 10.101.99.162 port: 7006".

 

-----------------------------------------------------------------------------------------------------------------------------------------------

More about what webtiers need, and ports in use.

 

(a) My 8.4.0.8.0 webtier (as well as all webtiers) only uses tcp/7022 for communication to the primary.

 

No other ports are needed.

 

example

webtier is 10.101.99.162, AM primary is 10.101.99.150

 

tcp        0      0 10.101.99.162:42196     10.101.99.150:7022      ESTABLISHED

 

(b) there is nothing on my webtier using port 7006 at all

 

(c) on my AM server, it does uses tcp port 7006 to connect to itself, port 7006 does not

ever need to connect to anything off the machine itself, no replicas, no webtiers...etc.

 

But the log does show unsuccessful attempts.

(NOTE: in my lab setup there are zero iptables and zero firewalls between AM Primary and my webtier 10.101.99.162, so I do allow port

7006 to connect if it could, but of course there is no port 7006 on the webtier.)

 

(d) Investigating port 7006 on my primary: it belongs to AdminServer (connecting to itself, no other machine)

This is for 'weblogic server wrappers' for various internal weblogic functions.

 

netstat -Tnlutp | egrep '^(tcp|udp)' | awk '{split($NF,p,"/");pscmd="ps --no-heading -fp " p[1] "|tr -s [:space:]";pscmd|getline psout;close(pscmd);split(psout,ps," ");x=index(psout,"-Dweblogic.Name=");if(x>0){split(substr(psout,x+16,20),pn," ");pname="AM: " pn[1];}else{x=index(psout,ps[8]);pname=substr(psout,x);}; printf("PID: %15s %3s | CONNECT: %-30s | %8s | PROCESS: %s\n",$NF,$1,$4,ps[1],pname); }'

 

PID: 2167/java tcp | CONNECT: 127.0.0.1:7006 | rsaadmin | PROCESS: AM: AdminServer
PID: 2167/java tcp | CONNECT: ::1:7006 | rsaadmin | PROCESS: AM: AdminServer
PID: 2167/java tcp | CONNECT: 10.101.99.150:7006 | rsaadmin | PROCESS: AM: AdminServer

 

INFO | jvm 1 | main | 2019/12/13 16:15:07 | <Dec 13, 2019 4:15:07,139 PM EST> <Notice> <Server> <BEA-002613> <Channel "AdminChannel" is now listening on 10.101.99.150:7006 for protocols admin, ldaps, https.>

 

(e) Investigating all ports on my webtier, AdminServer uses it's own connections to itself: none are 7006

 

netstat -nlutp | egrep '^(tcp|udp)' | awk '{split($NF,p,"/");pscmd="ps --no-heading -fp " p[1] "|tr -s [:space:]";pscmd|getline psout;close(pscmd);split(psout,ps," ");x=index(psout,"-Dweblogic.Name=");if(x>0){split(substr(psout,x+16,20),pn," ");pname="AM: " pn[1];}else{x=index(psout,ps[8]);pname=substr(psout,x);}; printf("PID: %15s %3s | CONNECT: %-30s | %8s | PROCESS: %s\n",$NF,$1,$4,ps[1],pname); }'


PID: 9328/java tcp | CONNECT: 127.0.0.1:8008 | rsaadmin | PROCESS: AM: AdminServer
PID: 9328/java tcp | CONNECT: 10.101.99.162:8008 | rsaadmin | PROCESS: AM: AdminServer
PID: 9328/java tcp | CONNECT: 127.0.0.1:7030 | rsaadmin | PROCESS: AM: AdminServer
PID: 9328/java tcp | CONNECT: 10.101.99.162:7030 | rsaadmin | PROCESS: AM: AdminServer
PID: 9328/java tcp | CONNECT: 127.0.0.1:7036 | rsaadmin | PROCESS: AM: AdminServer
PID: 9328/java tcp | CONNECT: 10.101.99.162:7036 | rsaadmin | PROCESS: AM: AdminServer

PID: 9328/java tcp | CONNECT: 127.0.0.1:32001 | rsaadmin | PROCESS: AM: AdminServer

 

 

---

All I can suggest is what you are seeing is a function that is not used, and has not been completely stripped out, so it is harmless and part of routine weblogic operations on the AM primary.

View solution in original post

2 Likes
Share
Reply
3 Replies
EdwardDavis
Employee EdwardDavis
Employee
‎2019-12-17 09:34 AM
  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Subscribe to RSS Feed
  • Permalink
  • Print
  • Email to a Friend
  • Report Inappropriate Content

Jump to solution

Port 7006 is not needed and not used. But weblogic on the Primary AM server does log the attempts.

 

My 8.4.0.8.0 AM Primary system does have a log file indicating errors connecting to my webtier 10.101.99.162 on port 7006, but it doesn't need this...this must be some leftover in the code where weblogic is trying a full list of options, but we don't happen to need port 7006 to actually connect to a webtier. So, this error is really something to ignore...

 

From a log file in my AM Primary /opt/rsa/am/server/logs directory:

 

INFO | jvm 1 | main | 2019/10/17 11:03:24 | java.net.ConnectException: Tried all: 1 addresses,

but could not connect over HTTPS to server: 10.101.99.162 port: 7006".

 

-----------------------------------------------------------------------------------------------------------------------------------------------

More about what webtiers need, and ports in use.

 

(a) My 8.4.0.8.0 webtier (as well as all webtiers) only uses tcp/7022 for communication to the primary.

 

No other ports are needed.

 

example

webtier is 10.101.99.162, AM primary is 10.101.99.150

 

tcp        0      0 10.101.99.162:42196     10.101.99.150:7022      ESTABLISHED

 

(b) there is nothing on my webtier using port 7006 at all

 

(c) on my AM server, it does uses tcp port 7006 to connect to itself, port 7006 does not

ever need to connect to anything off the machine itself, no replicas, no webtiers...etc.

 

But the log does show unsuccessful attempts.

(NOTE: in my lab setup there are zero iptables and zero firewalls between AM Primary and my webtier 10.101.99.162, so I do allow port

7006 to connect if it could, but of course there is no port 7006 on the webtier.)

 

(d) Investigating port 7006 on my primary: it belongs to AdminServer (connecting to itself, no other machine)

This is for 'weblogic server wrappers' for various internal weblogic functions.

 

netstat -Tnlutp | egrep '^(tcp|udp)' | awk '{split($NF,p,"/");pscmd="ps --no-heading -fp " p[1] "|tr -s [:space:]";pscmd|getline psout;close(pscmd);split(psout,ps," ");x=index(psout,"-Dweblogic.Name=");if(x>0){split(substr(psout,x+16,20),pn," ");pname="AM: " pn[1];}else{x=index(psout,ps[8]);pname=substr(psout,x);}; printf("PID: %15s %3s | CONNECT: %-30s | %8s | PROCESS: %s\n",$NF,$1,$4,ps[1],pname); }'

 

PID: 2167/java tcp | CONNECT: 127.0.0.1:7006 | rsaadmin | PROCESS: AM: AdminServer
PID: 2167/java tcp | CONNECT: ::1:7006 | rsaadmin | PROCESS: AM: AdminServer
PID: 2167/java tcp | CONNECT: 10.101.99.150:7006 | rsaadmin | PROCESS: AM: AdminServer

 

INFO | jvm 1 | main | 2019/12/13 16:15:07 | <Dec 13, 2019 4:15:07,139 PM EST> <Notice> <Server> <BEA-002613> <Channel "AdminChannel" is now listening on 10.101.99.150:7006 for protocols admin, ldaps, https.>

 

(e) Investigating all ports on my webtier, AdminServer uses it's own connections to itself: none are 7006

 

netstat -nlutp | egrep '^(tcp|udp)' | awk '{split($NF,p,"/");pscmd="ps --no-heading -fp " p[1] "|tr -s [:space:]";pscmd|getline psout;close(pscmd);split(psout,ps," ");x=index(psout,"-Dweblogic.Name=");if(x>0){split(substr(psout,x+16,20),pn," ");pname="AM: " pn[1];}else{x=index(psout,ps[8]);pname=substr(psout,x);}; printf("PID: %15s %3s | CONNECT: %-30s | %8s | PROCESS: %s\n",$NF,$1,$4,ps[1],pname); }'


PID: 9328/java tcp | CONNECT: 127.0.0.1:8008 | rsaadmin | PROCESS: AM: AdminServer
PID: 9328/java tcp | CONNECT: 10.101.99.162:8008 | rsaadmin | PROCESS: AM: AdminServer
PID: 9328/java tcp | CONNECT: 127.0.0.1:7030 | rsaadmin | PROCESS: AM: AdminServer
PID: 9328/java tcp | CONNECT: 10.101.99.162:7030 | rsaadmin | PROCESS: AM: AdminServer
PID: 9328/java tcp | CONNECT: 127.0.0.1:7036 | rsaadmin | PROCESS: AM: AdminServer
PID: 9328/java tcp | CONNECT: 10.101.99.162:7036 | rsaadmin | PROCESS: AM: AdminServer

PID: 9328/java tcp | CONNECT: 127.0.0.1:32001 | rsaadmin | PROCESS: AM: AdminServer

 

 

---

All I can suggest is what you are seeing is a function that is not used, and has not been completely stripped out, so it is harmless and part of routine weblogic operations on the AM primary.

2 Likes
Share
Reply
BadrHoussni
BadrHoussni Beginner
Beginner
In response to EdwardDavis
‎2019-12-17 10:01 AM
  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Subscribe to RSS Feed
  • Permalink
  • Print
  • Email to a Friend
  • Report Inappropriate Content

Jump to solution

Thanks Edward for your quick response.

I couldn't find any PID / or established sessions to the AM's with the port 7006.

 

From what i can see, the Webtiers starts to communicate with AM with the 7006 port when we were updating AM's from 8.4 P3 to 8.4 P8.

 

As far as i'am concerned, it's not important / relevant since everything is working fine. but i think that it should at least be documented or said that WT or AM communicate on 7006 port in some cases.

1 Like
Share
Reply
EdwardDavis
Employee EdwardDavis
Employee
In response to BadrHoussni
‎2019-12-17 10:33 AM
  • Mark as New
  • Bookmark
  • Subscribe
  • Mute
  • Subscribe to RSS Feed
  • Permalink
  • Print
  • Email to a Friend
  • Report Inappropriate Content

Jump to solution

Hi,

 

Well they really don't use 7006 ...you can 100% block everything except tcp/7022 and everything will work. I think (but I am not a programmer or developer so this is my best guess...) that since there is a full blown yet somewhat stripped down weblogic on both the AM server and a webtier, weblogic tries a 'pick list' of routine functions in all setups, and it is better to just let the ones that we do not use run and fail, than to surgically pick them apart and re-engineer weblogic to be 100% tuned to webtier functions only. Often large chunks of code will run X number of common functions, and the particular server and install uses only a subset Y of functions. So, the leftover unused pieces will 'fire, and fail' but really aren't needed and it's probably safer and more secure to leave them in that state...otherwise (again, total guesswork here) it may make it hard or impossible to lay down future patches and important security rollups from Oracle. By leaving weblogic 'alone' we can take a future patch from Oracle and it will install correctly since we didn't strip out all the internal bits. Likely makes it more robust overall despite the leftover errors and functions we don't use.

1 Like
Share
Reply
Powered by Khoros
  • Blog
  • Events
  • Discussions
  • Idea Exchange
  • Knowledge Base
  • Case Portal
  • Community Support
  • Product Life Cycle
  • Support Information
  • Customer Success
  • About the Community
  • Terms & Conditions
  • Privacy Statement
  • Provide Feedback
  • Employee Login
© 2022 RSA Security LLC or its affiliates. All rights reserved.