setting nxt.properties user permissions to 700?

Would userpermissions on nxt.properties / nxt-default.properties be safely protected by
"chmod 700 nxt.properties"

I would like to do this to keep my list of peers protected from external viewers. Do peers coming via/from/through my PeerServerPort need to be able to access this file, nor not? I was thinking that the user running the run.sh script for the node then in its process, sends those port numbers to the peers in nxt.wellKnownPeers via the blockchain process, so that no one else needs permissions to even read the nxt.properties or nxt-default.properties file.

Am I correct?
Because I do not want my nxt.wellKnownPeers= peers IP address ; peers IP address ; accessible
to prying eyes.

Is there somewhere else API users can see the node IP addresses even if I do not want them to?

Where else and why (if it is the case) are node addresses exposed to foreign parties not running the network of nodes.... {× last question plz

Do peers coming via/from/through my PeerServerPort

the service working on that port doesn't allow access to the file system or any other access which is controlled by the OS user permissions.

1 Like

Hi thank you. And there is no API request in the wallet for exposing peer IP addresses, for wallet users not running any node? I should hope not?!

Wait, the peers to which your node is connected ARE exposed. They are returned by both the API service and the peer service. You were asking if the nxt.properties file can be read through the services ardor provides - it cannot be read, so the permissions you set on that file are not important. But this doesn't mean that someone cannot deduce what you wrote in wellKnownPeers (or other properties) by observing the responses from your node.

Hi thank you. It would be great if this exposure was optional somewhere as a setting so that only hosting nodes can see this. Maybe it's a silly idea of mine. But I mean for example. What if you had
"Public Peer = yes/no"
or
"Hidden Peer = yes/no
in nxt.properties.

Couldn't this be done somehow as an additional security measure I mean, so that there are some hidden nodes and the others are "public nodes" and the hidden nodes only relay to to a few nodes, ,kind of as.. o well. I don't know. But I really thought it would be possible to hide some nodes' IP addresses completely except from some specific nodes and the other "public" nodes don't connect directly to it?

Please provide more details about your use-case. Why do you want to hide some nodes' IP addresses completely except from some specific nodes and the other "public" nodes don't connect directly to it? What's the purpose of the hidden nodes?

I am planning at least making one NXT "1" clone. I also do not have and cannot obtain source code for Android full node , which is pretty amazing btw, if I remember correctly, but I don't want my clients involved on that level anyway. But, so my android wallet would only be a WebView leading to one node. I would want some nodes hidden to make part of the blockchain invisible from some other parts (selection of nodes), and visible to only some "core nodes" to reduce the "attack surface". These 'core' nodes would liaise between public and private node selections.

For example if I run a node in Docker on a server at an ISP, and no one from the "public peers" receive signals their address broadcast is hidden, if that's possible, only some nodes who have public and say hidden/private node connections, no one would know that there are blockchain nodes on that server Docker container not the ISP, not the public, not even many peers in the "public peers" or "private-peer = no" category.

And how can you attack something you don't know exists? It's impossible.

Like, if there's a tree in a forest and there is no one around to hear it, does it make a sound?

Only on some nodes (that say, connect "public" and "private/hidden", i.e 'core nodes') those hidden peers are in the nxt.properties files with its specification, user permissions preventing access from all except the user running that Docker container, and those nodes serve as a relay between "private" and "public" nodes, theoretically. I am not sure I am making sense.

But I was thinking about another problem, of having in android, as the WebView URL, several webaddresses, with if (no HTTPS response); then (go to next ip address); for wallet. Because this webapp WebView is not a full node (because it's only a WebView on a phone pointing to one ip to access the wallet GUI/API), and then if your one WebView URL is attacked or too much traffic and no HTTPS response, then at least the WebView can query another option in the WebView URL list of options. But this would be another subset, of "WebView" wallet nodes, from the "public nodes" set, for example. However I am not technically capable of that, but thought I might save $15 and not need CloudFlare protection for all my nodes, by hiding their responses in the API etc. If it is possible, so no one can see them, only the person who runs them and the "core relay" nodes between "private" and "public" nodes. Why do I want this also is because I am literally broke and can't afford $15 for CloudFlare because I lost all my money from cryptoland, and am too sick to work or be useful really, I was trying to think of a cheaper way to reduce or avoid attacks if some spiteful people wanna destroy my blockchain, and improve uptime, but I don't know if my ideas are valid.

I'm aware that WebView "node selection"(multiple nodes in an if statement as the WebView URL) with HTTPS response checks to relay the user to an ip with an API that is responding to the URL HTTPS response check request statement, can be made visible by reverse engineering the apk, but maybe a further mix-up can be made, so that there is not just such a (static) list/set of "wallet-public nodes" testing HTTPS responses to guarantee uptime - without outsourcing to Cloudflare for Round Robin -, but a mix up too so that the timing of a node's uptime for login via the WebView app is limited - once you login, your WebView to that specific (URL address) won't close for the one device, but the URLs in the background process on the android changes to another list of IP addresses excluding the one IP you are currently on which is only being used temporarily in cache or volatile memory, which can be cleared from your phone also in the android app/ apk, so that, if you logout and log back in you would most certainly or if you are very lucky you may not, unless the previous is excluded, go to another wallet API login server, while the WebView URL has already been overwritten with another, even bunk(fake/unusable) address while you were still logged in, until you request a new one when you open the app again, later .. more ideas for trying to get more protection because those ip address options in the WebView URL could for even more obfuscation and anonymity of the blockchain, be called from a file or script on one of "those" (or other) servers, each which again could even be firstly, just servers with their own file/process receiving updated IP addresses from servers with dynamic addresses, of unique "wallet-now 'public' " servers for the webapp to choose from after testing them for HTTPS response, and login to, and after login, logging in triggers again that process of randomly selecting a server with a process receiving a list of possible dynamic IP addresses for GUI/API login , which are tested HTTPS responsive positive, mixing the possible GUI IP addresses, and so they are changed while your login instance still runs on the selection you made in temporary ram, as I've already said. So there are a bunch of information relay servers who are sending push notifications also, to your webapp refreshing their IP status when they change. So this new webview URL address being pushed to your phone is not a lot if data/bandwidth. Or in other words, it firstly mixes some sites that each run a script that provides a list / different lists, of wallet GUI/API ip addresses from servers thatbemit to these info relay servers, their new and current IP address, and returns the result, randomly selected from all HTTPS response positive IP addresses as the encrypted finalised WebView URL for that instance only on that device which you are then directed to in the WebView so that you can login to the node wallet there, and it goes to offer another finalized URL, a bunk or real one maybe not sure, after you login because you're running in volatile ram on that connection while logged in while the file is overwritten with a different IP address as the "official WebView URL" while you're not even using it anymore as you're in RAM/cache in the previous IP address, overwritten with a new address, which you are not on and won't use in this logged in instance. I mean if you could run servers that have dynamic IP addresses sending out signals to these WebView "relay processing servers," who themselves send with push processes their own new dynamic IP address,... to give them their new ip, so that you connect only during that window period and then the WebView URL is "officially" changed. It would still send info to your android, because you have a connection to that server open through certain ports even though its i.p has changed, but it can inform itself of the new address and relay that to your WebView URL and update it (so you can send to it also,) in the volatile ram or cache or wherever this process is running, while at the same time another new (not necessarily valid at all valid alternative displays/ is written into /as the WebView URL, but is not connected to, while you are on the previously selected and changing dynamic IP server. Because then you are running on that process of that server even if it has renewed its address while you are on it. Such a situation could create havoc for anyone trying to hack or invade privacy. I don't know if I'm wrong, or if it's possible, or if I'm making sense, it's too late at night and I did not mean to type so much.

And it could be encrypted to only go to that one device (the selected, HTTPS response positive tested IP, for the GUI/API) - it selects an ip, and connects you to it while the possible HTTPS responding ip list changes/shuffles, excluding the one you're logged into, and the IP address of the server you are on changes randomly and you don't lose connection even if it changes its ip, because it is sending signals to your device and can inform your device of the change /new address so that you don't lose the connection and can keep sending signals to it/ the "new address", etc? And all of this wiped from cache on the phone when logging out as part of the webapp?

Sorry I'm not a real programmer but it's interesting and I wish I could actually program or try to implement such ideas, but even if I could I would still need feedback to say if it works or why it won't work, etc... also it's very late I hope I made some sense, thank you.

Please correct me if I misunderstood: the purpose of the hidden nodes is that they will provide an open API and your android app will connect to their API service. So these nodes are connectable from the internet and you hope that not advertising their IPs over the peer service will help you with the security.

Beware that decompiling your app is not the only way to understand where its WebView loads from. If you app is connecting to some service there is no way to prevent a tech guy to understand the IP of that service.

lol That's sad news. I'm just worried because what if you have such a blockchain and you don't have cloudflare / roundrobin for your Webview url? It could easily be taken down with a DDOS... :frowning:

Yes but the IP nodes the IT guy can see are not directly connected to the hidden nodes. The hidden nodes are a separate collection of nodes that only send messages to specific nodes, those have both hidden and public nodes as their peers. The nodes the app connects to are not (those) hidden nodes, the app connects to some public nodes. But it only temporarily displays these wallet login nodes via encryption with auto update of their dynamic IP addresses that IP address in the RAM, while overwriting the WebView url, so that only that one device at that time during login in its cache can see that IP. And, that IP changes because its not static... So they would be different (those public wallet nodes) from other hidden nodes.

Do you maybe have a suggestion what I can do to prevent DDOS attacks (Without CloudFlare? Because obviously I will have to do loadbalancing and that is not possible without loadbalancing and DDOS protection) because if I manage to finish my project, it is for a political movement and sadly I am afraid, it will come under attack by people for fun, or also because a lot of people are against that movement... I also do not even believe in this movement's ideologies but am trying to change that ideology by using a NXT clone voting system, in the hopes that the different branches of that organisation maybe will adopt it, especially once it is actually listed on exchanges.

Maybe by that time I will have enough money, but I am just trying to understand better what the actual attack vectors are for a NXT clone that only runs on virtual servers and has no android full nodes.