DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Security

OpenBSD Security Functionally paranoid!

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 25th March 2021
jonsec jonsec is offline
Fdisk Soldier
 
Join Date: Jul 2019
Posts: 68
Default nc(Netcat) security configuration

In association with "how i can install the ftp server in OpenBSD?"
i chose nc instead of ftp because of speed & simple.

i want to transfer large encrypted file by nc from MyServer to BackupServer.

step by step :
1) connect to BackupServer from MyServer by ssh and run : nc -l -p 1234 > largefile.enc.gz
2) MyServer# nc -w 3 BackupServer 1234 < largefile.enc.gz

Port 1234 of BackupServer is only allowed for MyServer in pf.

Is there another security setting?
Reply With Quote
  #2   (View Single Post)  
Old 25th March 2021
jggimi's Avatar
jggimi jggimi is online now
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,634
Default

That's a workable solution. Consider adding -N to close the pipes. You can also use X.509 certificates and TLS with nc(1) so that the file can be encrypted/decrypted in flight instead of being staged through a cipher utility like openssl(1). But that's similar to sftp(1) or scp(1) in network throughput.
Reply With Quote
  #3   (View Single Post)  
Old 25th March 2021
IdOp's Avatar
IdOp IdOp is offline
Too dumb for a smartphone
 
Join Date: May 2008
Location: twisting on the daemon's fork(2)
Posts: 1,018
Default

Quote:
Originally Posted by jggimi View Post
... so that the file can be encrypted/decrypted in flight instead of being staged through a cipher utility like openssl(1). But that's similar to sftp(1) or scp(1) in network throughput.
It raises an interesting point. As much as it can be frustrating to wait for a file to cross the network more slowly with the encrypted tunnel, OTOH if using netcat (or other unencrypted transport) then the file has to be encrypted before transit and decrypted afterwards. That will increase the total time to do the job, which may be a more important metric than network transit time. Which way is "better" will probably depend on many factors so I doubt there's a simple answer.

I had a couple of other general thoughts for jonsec:

A) Writing largefile.enc.gz suggests that the file encryption is done first, followed by compression. I suspect this isn't the best order to do it. The encrypted file should be very random and probably won't compress well due to that. So if the compression is done first, there is a possibility of getting good compression (if the material isn't already in a compressed form, like an MPG). This would lead to largefile.gz.enc. Having a smaller file would give better network transit times (and less disk space usage, etc.).

B) A given port, such as 1234, might already be in use by another process on the target machine (though probably unlikely, depending on the circumstances). If you want to automate this to some extent (e.g., use a shell script to set up the receiving nc process) you might want to use a small range of ports, e.g., 1234-1238, and use the first free one. Or use a random port in a larger range. This would affect what you do, or can do, with pf of course.

Last edited by IdOp; 25th March 2021 at 04:13 PM. Reason: r <--> o
Reply With Quote
  #4   (View Single Post)  
Old 28th March 2021
jonsec jonsec is offline
Fdisk Soldier
 
Join Date: Jul 2019
Posts: 68
Default

Quote:
Originally Posted by jggimi View Post
That's a workable solution. Consider adding -N to close the pipes. You can also use X.509 certificates and TLS with nc(1) so that the file can be encrypted/decrypted in flight instead of being staged through a cipher utility like openssl(1). But that's similar to sftp(1) or scp(1) in network throughput.
a good security tip.

Quote:
Originally Posted by IdOp View Post
A) Writing largefile.enc.gz suggests that the file encryption is done first, followed by compression. I suspect this isn't the best order to do it. The encrypted file should be very random and probably won't compress well due to that. So if the compression is done first, there is a possibility of getting good compression (if the material isn't already in a compressed form, like an MPG). This would lead to largefile.gz.enc. Having a smaller file would give better network transit times (and less disk space usage, etc.).
a good performance tip.
Reply With Quote
Reply

Tags
nc, netcat

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
ssh configuration diarra General software and network 3 2nd September 2014 07:03 PM
Help with PF NAT configuration scrummie02 OpenBSD Security 12 10th November 2011 04:45 AM
PF NAT configuration help ikevinjpdev OpenBSD Security 0 7th August 2010 04:41 PM
k3b, configuration. maxrussell FreeBSD Ports and Packages 4 3rd March 2009 04:23 AM


All times are GMT. The time now is 01:28 AM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick