Re: Is FTP through haproxy at all viable?
I consider openssh for sftp pretty much unusable for clients/customers. I wouldn’t say that. Certainly true if they don’t actually know what they’re doing. As for the setup: yes, the first directory users can write to in a chroot-setup is a subdirectory of the home directory (because $HOME needs to be owned by root). But everything else is pretty simple. You don’t need any special devices or other stuff in the chroot itself. It basically just works in my experience. If you want to chroot a full, interactive shell, though, you’re jumping into a world of pain… Doesn’t have much to do with haproxy, though. Personally, I’m not sure if load-balancing FTP is worth the effort. Also, it looks like it’s quite „fragile“ and as such the load-balancing might break more often than a single-server without load-balancing.
Best wholesale price of latest 3G camera
DearSirorMadam, Hopethingsarewellwithyou. Bytheway,Wesupply oneofournbs=p;3Gnewworkcameraswhichsellespeciallywellforyourreference.Ev=erymonth ,weallexportover5pcstoUSA and Euro=pe.,welcomeyourinquiries ,thanks. OEM,ODMareavailable. ModelNo.:SM-336GWelookforwardtohearingfromyou. BestRegardsJenny ContactUS:Company Name:SmartShineTechnologyCo;Ltd=.Address:2Building,T=ongle IndustryPark ,NanshanRoad,Nanshan Industry,S=henzhen,China.ContacPerson;Jenny=YiTel:0086=1352887=1-267Fax:008675526187082Skype : pol=lyyi471Email: pollyyu...@hotmail.com nbs=p; i...@szsmartshine.com Website: =nbsp;www.szsmartshine.com= nbs=p; .
Re: Is FTP through haproxy at all viable?
On 09.05.2015 21:50, Shawn Heisey wrote: On 5/9/2015 11:43 AM, Dennis Jacobfeuerborn wrote: Most FTP clients these days support SFTP as well and if you use say proftpd+mod_sftp then handling SFTP on the server side become pretty much identical to handling FTP (except all that active/passive nonsense goes away an nobody can simply sniff passwords on the wire). There are dozens of clients out there among our customer base, many of which have been using the same software for the last ten years or more, and most of that old software is probably written by an internal developer that quit years ago, not an off-the-shelf FTP/SFTP client. When we finally manage to get a server for SFTP installed, we can ask our clients to switch, but I'm sure many of them will think we're insane. Yes with these kinds of legacy clients there is little one can do since their requirements are their requirements and that's that. I've seen plenty of admins who still hand out FTP accounts simply because that's how it has always been done thus keeping these outdated protocols alive artificially. When I talk to customers and they ask for FTP I simply offer them SFTP instead which is more secure and the usually accept it right away. I will look into the sftp module for proftpd. Hopefully that will be easier to secure than openssh. It can be tricky to make sure clients don't get shell access and are chrooted into their home directory when using openssh. It's not impossible, just challenging. I consider openssh for sftp pretty much unusable for clients/customers. Since I setup 99% of account with chroots the mere fact that one has to create a proper jail and then confine a user to a sub-directory of their home directory for security reason makes this way to much of a pain in the behind. With mod_sftp you create an empty home directory for that user and then tell proftpd to chroot users to their home directory and you are done. No building of jails and thus *way* easier to deal with. Regards, Dennis
Re: Stick tables and counters persistence
On Fri, Apr 17, 2015 at 9:46 PM, Dennis Jacobfeuerborn denni...@conversis.de wrote: Yes, you add a peer section: peers haproxy-peers peer haproxy1 127.0.0.1:1024 (haproxy1 must the the hostname of the local system) and then you add a reference to that peer section in you stick table definition for example: stick-table type ip size 100k expire 20m peers haproxy-peers On a reload the new process will then sync the stick table from the old process. If you want to do SSL offloading (and thus need nbproc1) the best workaround I found is to setup two haproxy instances (systemd makes that pretty easy) one for the SSL offloading (nbproc1) which then forwards the traffic using abstract namespace socket to the other instance (nbproc=1) that does the actual load-balancing. That way you can reload the balancing instance keeping the stick tables but also utilize multiple cpu cores for SSL offloading. Regards, Dennis On recent update it is given that now nbproc can be used along with peers. Another improvement consists in a relax of the restriction between peers and nbproc. Now it is possible to use peers provided that the whole section is only used by tables belonging to the same process. This makes it easier to run SSL offloading in multiple processes now. Ah, and it's also possible to disable a peers section without having to comment all places where it's referenced! Can anyone provide a sample/example config for same? Jai
Re: Is FTP through haproxy at all viable?
On 5/9/2015 2:04 AM, Malcolm Turnbull wrote: LVS with FTP works fine in the current kernels but does need the correct firewall modules loaded + conntrack enabled. I was really hoping to avoid that, but the more I've read, the more I've dreaded that the firewall would be required. Setting it up in haproxy would allow me to drop dependence on the kernel load balancer, which would be really nice. You can do active and passive FTP with HAProxy. Active needs TPROXY so the server can see the client IP address, it also needs iptables rules on the FTP servers to make sure they reply on the right address. Passive is simpler but requires a bit of fiddling on the FTP server, we have several examples in our manual here (page 168): http://pdfs.loadbalancer.org/loadbalanceradministrationv7.pdf After a quick glance, this is probably good, but there's a hiccup ... these instructions use a GUI to configure haproxy and iptables commands to configure the firewall. I don't have this GUI, and I'm on ubuntu, which uses ufw to configure the firewall. Therefore I need actual haproxy config and firewall config that is specific to ufw, preferably something I can drop into the /etc/ufw/applications.d directory. The world would be a much nicer place if every one used SSH/SCP/SFTP and FTP was never invented :-). I totally agree. Not sure what the original author was smoking, having the server make a separate connection directly to the client. Passive mode is a slight improvement, except that now there are two different ways of doing it, and you never know which method will be available to your users. Unfortunately FTP is extremely widespread and grasped by customers, and it can be difficult to secure SFTP properly on the server side. Thanks, Shawn
Re: [PATCH 0/3] Add support for TLS ticket key socket updates
On 09/05/2015 08:45 πμ, Nenad Merdanovic wrote: This patchset adds support for updating TLS ticket keys using the admin socket. Nenad Merdanovic (3): MINOR: Add TLS ticket keys reference and use it in the listener struct MEDIUM: Add support for updating TLS ticket keys via socket DOC: Document new socket commands show tls-keys and set ssl tls-key Are TLS tickets shared in case of nbproc 1? Thanks a lot for this feature and the way you implemented it. Great work, Pavlos signature.asc Description: OpenPGP digital signature
Re: Is FTP through haproxy at all viable?
On 5/9/2015 11:43 AM, Dennis Jacobfeuerborn wrote: Most FTP clients these days support SFTP as well and if you use say proftpd+mod_sftp then handling SFTP on the server side become pretty much identical to handling FTP (except all that active/passive nonsense goes away an nobody can simply sniff passwords on the wire). There are dozens of clients out there among our customer base, many of which have been using the same software for the last ten years or more, and most of that old software is probably written by an internal developer that quit years ago, not an off-the-shelf FTP/SFTP client. When we finally manage to get a server for SFTP installed, we can ask our clients to switch, but I'm sure many of them will think we're insane. I will look into the sftp module for proftpd. Hopefully that will be easier to secure than openssh. It can be tricky to make sure clients don't get shell access and are chrooted into their home directory when using openssh. It's not impossible, just challenging. Thanks, Shawn
[PATCH 1/3] MINOR: Add TLS ticket keys reference and use it in the listener struct
Within the listener struct we need to use a reference to the TLS
ticket keys which binds the actual keys with the filename. This will
make it possible to update the keys through the socket
Signed-off-by: Nenad Merdanovic nmer...@anine.io
---
include/types/listener.h | 3 +--
include/types/ssl_sock.h | 8
src/cfgparse.c | 6 +-
src/ssl_sock.c | 17 +++--
4 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/include/types/listener.h b/include/types/listener.h
index 142e845..895cd00 100644
--- a/include/types/listener.h
+++ b/include/types/listener.h
@@ -132,8 +132,7 @@ struct bind_conf {
int strict_sni;/* refuse negotiation if sni doesn't match a
certificate */
struct eb_root sni_ctx;/* sni_ctx tree of all known certs
full-names sorted by name */
struct eb_root sni_w_ctx; /* sni_ctx tree of all known certs wildcards
sorted by name */
- struct tls_sess_key *tls_ticket_keys; /* TLS ticket keys */
- int tls_ticket_enc_index; /* array index of the key to use for
encryption */
+ struct tls_keys_ref *keys_ref; /* TLS ticket keys reference */
#endif
int is_ssl;/* SSL is required for these listeners */
unsigned long bind_proc; /* bitmask of processes allowed to use these
listeners */
diff --git a/include/types/ssl_sock.h b/include/types/ssl_sock.h
index d769acd..4642124 100644
--- a/include/types/ssl_sock.h
+++ b/include/types/ssl_sock.h
@@ -38,4 +38,12 @@ struct tls_sess_key {
unsigned char hmac_key[16];
} __attribute__((packed));
+struct tls_keys_ref {
+ struct list list; /* Used to chain refs. */
+ char *filename;
+ int unique_id; /* Each pattern reference have unique id. */
+ struct tls_sess_key *tlskeys;
+ int tls_ticket_enc_index;
+};
+
#endif /* _TYPES_SSL_SOCK_H */
diff --git a/src/cfgparse.c b/src/cfgparse.c
index 8578bc5..e543dd8 100644
--- a/src/cfgparse.c
+++ b/src/cfgparse.c
@@ -7762,7 +7762,11 @@ out_uri_auth_compat:
free(bind_conf-ciphers);
free(bind_conf-ecdhe);
free(bind_conf-crl_file);
- free(bind_conf-tls_ticket_keys);
+ if(bind_conf-keys_ref) {
+ free(bind_conf-keys_ref-filename);
+ free(bind_conf-keys_ref-tlskeys);
+ free(bind_conf-keys_ref);
+ }
#endif /* USE_OPENSSL */
}
diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index eb1d88c..2029298 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -406,8 +406,8 @@ static int ssl_tlsext_ticket_key_cb(SSL *s, unsigned char
key_name[16], unsigned
int i;
conn = (struct connection *)SSL_get_app_data(s);
- keys = objt_listener(conn-target)-bind_conf-tls_ticket_keys;
- head = objt_listener(conn-target)-bind_conf-tls_ticket_enc_index;
+ keys = objt_listener(conn-target)-bind_conf-keys_ref-tlskeys;
+ head =
objt_listener(conn-target)-bind_conf-keys_ref-tls_ticket_enc_index;
if (enc) {
memcpy(key_name, keys[head].name, 16);
@@ -1783,7 +1783,7 @@ int ssl_sock_prepare_ctx(struct bind_conf *bind_conf,
SSL_CTX *ctx, struct proxy
}
#if (defined SSL_CTRL_SET_TLSEXT_TICKET_KEY_CB TLS_TICKETS_NO 0)
- if(bind_conf-tls_ticket_keys) {
+ if(bind_conf-keys_ref) {
if (!SSL_CTX_set_tlsext_ticket_key_cb(ctx,
ssl_tlsext_ticket_key_cb)) {
Alert(Proxy '%s': unable to set callback for TLS
ticket validation for bind '%s' at [%s:%d].\n,
curproxy-id, bind_conf-arg, bind_conf-file,
bind_conf-line);
@@ -4359,6 +4359,7 @@ static int bind_parse_tls_ticket_keys(char **args, int
cur_arg, struct proxy *px
FILE *f;
int i = 0;
char thisline[LINESIZE];
+ struct tls_keys_ref *keys_ref;
if (!*args[cur_arg + 1]) {
if (err)
@@ -4366,7 +4367,8 @@ static int bind_parse_tls_ticket_keys(char **args, int
cur_arg, struct proxy *px
return ERR_ALERT | ERR_FATAL;
}
- conf-tls_ticket_keys = malloc(TLS_TICKETS_NO * sizeof(struct
tls_sess_key));
+ keys_ref = malloc(sizeof(struct tls_keys_ref));
+ keys_ref-tlskeys = malloc(TLS_TICKETS_NO * sizeof(struct
tls_sess_key));
if ((f = fopen(args[cur_arg + 1], r)) == NULL) {
if (err)
@@ -4374,6 +4376,8 @@ static int bind_parse_tls_ticket_keys(char **args, int
cur_arg, struct proxy *px
return ERR_ALERT | ERR_FATAL;
}
+ keys_ref-filename = strdup(args[cur_arg + 1]);
+
while (fgets(thisline, sizeof(thisline), f) != NULL) {
int len = strlen(thisline);
/* Strip newline characters from the end */
@@ -4383,7 +4387,7 @@ static int bind_parse_tls_ticket_keys(char
