Re: [Burp-users] Security on 4971 port

[Tiago T. M. <tia...@dj...>]

Hi Morgan Smith!
Don't be feel bad (or felt. My english is like my kownlegde security. Bad :( )
I like your answer, realy!

My Burp server will be on the cloud. It will store backups of many Windows and Linux Desktops spread over the internet. My doubt is if there is a kind of any security about connections, mainly DDoS, in Burp when it need to listen backups on this port.
For example, I heard about send a large authentication package on a port. Will Burp wait all package or it's expect a fixed size authentication package and drop connection in this case?

When I said security actually I mean TCP/IP and others ethernet protocols. It was not be clear, sorry.
Any other security inside linux will be configurated, like permissions, run with a specific user and others things. A firewall + tools will be installed too. I just wanna know what kind of situation I need to prevent.

I don't think SSH tunnel and VPN is a good idea in my case. Many configuration need to be done on the client side, and these computers are no my.

Thanks!

On Wed, May 04, 2016 at 10:24:35AM -0600, Morgan Smith wrote:
> I feel bad about the novel but there are some decent points in here for
> your consideration.
> 
> Many DDoS style attacks are in my opinion a bit beyond the scope of the
> application layer of the OSI model. That said, one is not completely
> helpless against all and other styles of attack. Please note that while
> layered security is a great idea it is vital to define your threat model
> so as to better ensure some mitigating factor is put into place. Threats
> about denial of service come from both external and internal factors.
> Anybody with root access should understand they can become their worst
> problem if they become careless or reckless in their commands.
> 
> The certificates, the password auth, the server side client
> configuration files, and the ability to run burp as an unprivileged user
> all do a decent job at authenticating a client and protecting things at
> the application layer. I would recommend each burp client to use a
> unique password and certificate, and unique ssl keys and key passwords.
> 
> In the burp-server.conf there is a directive to specify which port is
> used. 4971 is the default and it can be changed. This obscurity isn't
> really security but can help avoid attracting attention from a simple
> blind scan for common services. This, combined with a firewall that
> detects and blocks port scanning can make some direct attacks more
> challenging.
> 
> On your burp server you may configure your firewall to only allow
> inbound connections from your various hosts and to deny all other
> connections. While that may not help against a DDoS attack it can be
> beneficial to filter connections at this lower layer in the stack which
> may not have the overhead of the application layer where authentication
> and certificates through burp are handled. My firewall also attempts to
> handle cases of invalid packet flag combinations and detection of port
> scanning which are other non-DDoS attacks.
> 
> LOL I have on rare occasion used an ssh tunnel (both forward and
> reverse) to encapsulate burp traffic so there were no burp ports on a
> public interface but that was to get around some odd restrictions in a
> network I had no control over. I have not yet tried burp backups over a
> VPN but I don't initially see any obvious problem outside of usual
> performance through a VPN.
> 
> I don't think my burp server compilation has support for tcpwrappers but
> it may be worth looking into if you like that extra layer of security. I
> haven't looked for pam support.
> 
> Depending on your threat model you may also wish to consider having the
> clients encrypt their data before sending it to the burp server, and
> furthermore you may wish to have the drives to your burp server
> encrypted themselves. Again, this depends on your threat model.
> 
> Regarding DDoS specific I don't see why a burp setup couldn't be
> instantiated on a high availability cluster or behind traffic shaping
> network appliances. One would have to choose their back end storage
> properly. I myself have only used burp with local storage as opposed to
> SAN/iscsi/ataoe or gluster or nfs. Obviously if you can perform the burp
> across a private network there are potential security advantages there.
> 
> Regarding protection against local failure (which technically denies
> service) it would be prudent to consider your storage having redundancy
> of devices as in RAID or gluster. It may also be wise to have such
> redundancy in multiple physical locations using a mirroring method of
> your choice (lvm snapshots, linux hot copy instance, burp's
> offsite-backup, lsync.
> 
> Also in the realm of local protection is offsetting your burp client
> backup times so you don't tie up the storage devices doing a lot of
> simultaneous shuffling, or tie up the network interface with concurrent
> streams.
> 
> Let us also not forget that security often comes down to the weakest
> link. If your host OS isn't up to date or if you follow relaxed security
> practices for user access, or haven't hardened your distro then there
> may be more important security considerations to review than burp itself.
> 
> On 05/04/2016 06:35 AM, Tiago Tarifa Munhoz wrote:
> > Hi all!
> > 
> > I would like to make backups over the internet from Windows and Linux clients to Linux Burp server.
> > Is there security features on port 4971 like avoid DDoS attacks or other attacks on server side? For example, send huge data on this port?
> > 
> > I'm not a security expert either so any doc or hint that improve my knowledge about that are welcome.
> > 
> > ------------------------------------------------------------------------------
> > Find and fix application performance issues faster with Applications Manager
> > Applications Manager provides deep performance insights into multiple tiers of
> > your business applications. It resolves application problems quickly and
> > reduces your MTTR. Get your free trial!
> > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> > _______________________________________________
> > Burp-users mailing list
> > Bur...@li...
> > https://lists.sourceforge.net/lists/listinfo/burp-users
> >