I installed the CheckPoint SecurePlatform R75.20 on my VirtualBox. I configured it. Now in order to create an OPSEC Application and proceed to maintaining a LEA server, i need to login to SmartDash Board. I define me (i.e my ip) as a GUI client, and tried to login to the SmartDash Board using the administrator usename and password (this is what needs to be done). But the login gets rejected saying "either host is dowm or user not a GUI client". In my case, host is up, as im ssh'ing into it and i have clearly mentioned my ip as a GUI client.
Where have i gone wrong?
Thanks.
To be able to logon to a CheckPoint SmartCenter you will have to;
Have network access to TCP port 18190 (CPMI) from your machine to the SmartCenter (which you probably have since its on your own LAB-network).
A username/password, which you created during the installation or can add or modify later using the command "cpconfig" and going to menu option "Administrator". (Note: only 1 administrator can be defined using cpconfig. Future administrators is defined inside SmartDashboard).
Your IP-address must be in the GUI client list. You can modify this by logging on to the SmartCenter machine with SSH, enter command "cpconfig" and go to menu option "GUI Clients".
Related
I am trying to scrape the contents of a webpage. My code works on a Windows 7 machine that has the same versions of the drivers as my Windows 10 machine.
When I run it on windows 10, it opens a selenium controlled window, but then returns None, instead of the scraped content. I have checked Xpaths, and everything is fine. It has the same code and drivers as the working code running on the windows 7 machine.
Debug Report Shows The Following Error :
[0803/010730.442:ERROR:process_reader_win.cc(123)] NtOpenThread:
{Access Denied} A process has requested access to an object, but has
not been granted those access rights. (0xc0000022)
[0803/010730.445:ERROR:exception_snapshot_win.cc(98)] thread ID 472 not
found in process
When setting up the gMSA (group Managed Service Account), although you didn't specify that, the error code references:
{Access Denied}
In some cases, it isn't just the user who requires rights on a given machine. gMSA accounts are at a computer level rather than a user level.
Is it possible that the target machine is attempting to access permission on the source machine? If that is the case, it could be for several reasons. If you are on a domain, the source server (the one being scraped on its web content), may not allow the target server account rights and it won't matter what code is used, the server (computer) will reject the rights before it checks the user access.
If on a local domain, it may be worth checking whether there is access for that port, though not probable as most everything runs on port 443, but perhaps the web page is on 1443 or 8443 or something similar and that port is not open on the domain (or private if you are running this in a home lab). This latter reason doesn't make sense because your web server would be open on that port, but it could be a port blocking issue as well as a block from computer to computer.
442 Error can also refer to a VPN issue where the VPN is blocking the access.
If it is a VPN error, there is a fix here:
https://www.vpndig.com/tutorial/fix-error-442-in-cisco-vpn
I am running the CUPS in Linux Debian machine. Using the CUPS I am sending the print request to Windows XP machine. I have enabled the 445 and 139 port and I am able to connect the Windows Machine. Printer is connected to the Windows Machine.
I am sending the print request using the following command
lp -E -d < Printer Name > file name.
After sending I am checking the printer status using the following command
lpstat -p < Printer Name >
I am getting the below error message when I execute the above message.
unable to connect to cifs host will retry in 60 seconds..
When I checked in the log I am getting the below error message.
session setup failed: NT_STATUS_LOGON_FAILURE and NT_STATUS_BAD_NETWORK_NAME
The DeviceURI is like below in /etc/cups/printers.conf
smb://username:password#IP Address of windows Machine/printer_Name
Please let me know if the password is having '#' symbol, how can we specify the '#' with actual syntax in DeviceURI ( user:password#IP )
Unfortunately you provide not enough detailed info about your specific setup. So I will make an effort to take several potential problems into account and give hints how to overcome them:
I.
Did you use the correct share name for your shared Windows printer?
To find out, use this command:
$ smbtree -U windowsusername
You might see something like the following output:
WORKGROUP
\\MURUGA-PC
\\MURUGA-PC\G
\\MURUGA-PC\Z
\\MURUGA-PC\Public
\\MURUGA-PC\print$ Printer Drivers
\\MURUGA-PC\EPSON Stylus CX8400 Series EPSON Stylus CX8400 Series
In other words: your printer's share name may contain spaces. But you cannot use spaces in the device URI for CUPS! What now?
Easy: (1) Either rename the share name on the Windows side. (2) Or escape the space by using %20 instead:
smb://muruga:mysecretpassword#muruga-pc/EPSON%20Stylus%20CX8400%20Serie
II.
Is your Windows XP by any chance using Kerberos authentication? For example, because it is part of an Active Directory environment? Then you should refer to this document on cups.org:
Configuring CUPS to Use Kerberos
Kerberos authentication does not work with username/password, it uses 'tickets'.
III.
Otherwise, if your Windows XP machine is part of a "standard" domain, you may be more successful by ditching your device URI of smb://username:password#ip-address-of-windows/printer_name and use this instead:
smb://username:password#domain_name/windows_host/printer_Name
The username you use has to be the Windows user name (with his/her password) who installed the printer on Windows!
IV.
Alternatively, you may have success by using IPP to print to Windows (though XP needs an IPP-enabling extension installed, provided by Microsoft). Be aware that MS is using a non-standard syntax for their device URIs (using port 80 or 443), and their version of IPP is still 1.0 (which always remained in "draft" status and never made it into an official release by the IETF):
DeviceURI https://mywindowsprintserver/printers/printername/.printer
or
DeviceURI http://mywindowsprintserver/printers/printername/.printer
For username/password authentication to this printer, you need
AuthInfoRequired username,password in /etc/cups/printers.conf and
DefaultAuthType Basic in cupsd.conf.
To use Kerberos, you need
AuthInfoRequired Negotiate in /etc/cups/printers.conf and
DefaultAuthType Negotiate in cupsd.conf.
If the whole setup is in a household with a private LAN/WLAN, you may want to consider removing all access controls (first on the Windows print server side, then):
AuthInfoRequired None in /etc/cups/printers.conf and
DefaultAuthType None in cupsd.conf.
If your problem is that your password contains a '#'-character, then try this:
smb://username:'p#ssword'#domain_name/windows_host/printer_Name
or
smb://username:p%40ssword#domain_name/windows_host/printer_Name
I'm trying to set up a remote desktop session for monitoring specific systems at my place of work. I only have access to a Linux machine and I need to connect via a terminal server gateway. I am using FreeRDP to do this and i am using the following command to create the connection:
xfreerdp /d:** /u:***** /p:******* /g:******.************.***
/v:****.*********.***** /port:3389 /size:1920x1080
I have hidden all connection details per my supervisors request however both he and I verified the correct information is entered into the fields.
When I send the connection through I get the following error:
Connected to ******.************.***:443
Connected to ******.************.***:443
TS Gateway Connection Success
Got stub length 4 with flags 3 and called 7
Got stub length 4 with flags 3 and called 6
SSL_read: I/O error: connection reset by peer (104)
Rpc_client_frag_read: error reading header
Would anyone have any idea of what I might be missing? I have even tried adding
/sec:rdp
to the script and even that produced the same error
Try rdp from a Windows system (or have someone else try from their system, since you don't have direct access to Windows). I know it won't solve your problem, but it may give you better information. I'm in a similar situation and got the same error message. I tried remmina instead of xfreerdp and got even less information than xfreerdp spits out.
From a Windows VM, at least I could tell when I got my domain\username & password right -- it told me my account was not allowed rdp access to that server. I'm figuring that means that there are accounts that can rdp in, but mine is not among them. Along the way, though, I found that the remote was using a certificate from an untrusted authority, which was useful information for my case.
If your Linux is old or hasn't been updated, do so. Your certificate store may be out of date. But it may also be that your company's Windows domain has certificates that Linux doesn't know about. It could be a simple matter that you're lacking the company-supplied cert (because they push it to all Windows machines on the domain, but your Linux machine doesn't get that "benefit").
I'm trying to get a deeper understanding of the architecture and design of Openstack noVNC security. I found this document. It makes sense but missing details. Can somebody confirm my understanding is right, or correct me if I'm wrong.
0) noVNC allows VNC clients in web browsers, good for clients without java or vnc client installed.
1) VNC server is provided by the hypervisor, Every VM has its own VNC server, at port 59xx, not accessible from outside.
2) Websocket proxy bridges to VNC server and provide service for noVNC client (javascript in browser), say at port 6080.
3) Simple security: Security could alternatively be guaranteed by VNC password, but it's not convenient to type every time and not easy to change. Every VM on the same hypervisor has to share the same password. Different compute nodes may use different VNC passwords.
4) To provide better access control, consoleauth is introduced. We can now use Openstack authentication for VNC. When a new request for remote console comes, a dynamic access URL (with a token) is generated, cached/registered, and sent back to client. Later, only previously registered connections are accepted.
I would like to know more about whether/how dynamic firewall rules are created, and whether/when the tokens are invalidated. I know the best way is to read the source code, but a high level description is also valuable. Thanks.
I'm trying to write an application that runs as a daemon and monitors
running X sessions. Right now I'm struggling to find documentation
regarding the X security model. Specifically, I'm attempting to
connect to running X displays from my daemon process. Calling
XOpenDisplay(dispName) doesn't work, I guess because my process
doesn't have permission to connect to this display. After a bit of
research, it looks like I need to do something with xauth.
In my test environment, the X server is started like this:
/usr/bin/X -br -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-QBEVDj
That file contains a single entry, that looks like this:
#ffff##: MIT-MAGIC-COOKIE-1 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
by adding an entry to ~/.Xauthority with the same hex key, I can
connect to the X server. However, this is difficult because I need to
programmatically find the auth file the X server is using (the
location of which I guess will change from distro to distro, and
probably from one boot to the next), then query it, then write a new
auth file. If the process is running as a daemon, it might not have a
home directory, so how do I know where to write the new entries to?
Ideally, what I'm looking for is a way to bypass the need to have the
xauth cookie in ~/.Xauthority, or even to know what the cookie is at
all. I realise that this is unlikely - what good is a security model
if it's easily bypassed? but I'm hoping someone on this list may have
a few good ideas. Is there a way to specify that my process is
privileged and thus should automatically be given access to any
display on the local machine?
You don't have to use a home directory if you specify an XAUTHORITY environment variable, which specifies the location of the .Xauthority file. Read the xauth man page.
But, in general, it's hard to locate the auth file, for the reasons you mentioned; also, this "fishing for auth tokens" approach would only work for local displays.
With regard to letting root (or some other user) connect to an X server willy-nilly, you'd probably have to patch the source code to do this, and you'd have to use something like getpeereid to obtain the connecting user's uid/gid (this only works on Unix-domain sockets, which I presume would be the type used for local connections, anyway).
Xauth is not the only security mechanism for X
There is also another one (less secure) that just performs IP based authentication
(See xhost).
So if you switch your X server to this less secure mode it will trust any connections coming
from the defined set of IPs.
This way you do not need to deal with Xauthority at all.