I am getting DDoS attack continuously since 20 days, tried almost everything, disabling and enabling plugins and all. Its not getting stopped. Need help.
security
use Cloudflare in order to protect against DDoS Layer 7 attacks for Layer 4 attacks I would recommend using an other provider for example OVH or any provider with good DDoS protection then you should be safe.
Also plugins won't help you much against an DDoS attack.
Related
Our Penetration testing Team is suggesting to configure Public Key Pinning Extension for HTTP at IIS level.
Wikipedia says it’s a deprecated security mechanism. And most of the blogs and articles not recommending pinning because it involves a huge risk.
https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning
https://threatpost.com/google-to-ditch-public-key-pinning-in-chrome/128679/
Is it any good to have PKP on a Web site?
Please Advice.
What I can make sure is that compared to websites that don’t use any certificates or encrypted connections, public key pinning can make connection safer. When Google first introduced PKP, it was used to add a layer of security for web clients.
But after so long of technological changes, more safer technologies appear, which make PKP looks not perfect.
By terminating the connection PKP can help protect end users from man-in-the-middle (MITM) attacks. One way a MITM attack can happen is when an attacker uses a fraudulent certificate to create a spoofed site in order to harvest user’s personal information.
Now it seems that PKP is not safe, few websites use it, and even many browsers are giving up support for it. I think your Penetration testing Team know this, but why they insist on using it, you need to ask them. They may have some specail reason for using PKP.
I want to buy SSL and add to my domain, but my concern is about performance and speed. my concern is: Will SSL affect the speed of my chat app ? as it is implemented with socket.io.
currently I am connecting with http : // mydomain.com but after adding SSL I would use https : // mydomain.com, so will https affect the speed of my socket.io app ?
My conditions is:
Performance and speed is a must
Security also is a must
If security is a must then you should use SSL. It prevents people from being able to listen in on your conversations so I wouldn't trust a site if it didn't have a signed SSL certificate.
The impact on performance is so negligible that I wouldn't worry about it. There are so many other things you can do to improve the speed of your app that if your app is ever noticeably slow, it probably won't be due to SSL.
Obviously, if security is important to you, then you should indeed encrypt your network traffic with SSL/TLS.
There is technical overhead to establishing a new SSL/TLS session, and encrypting/decrypting traffic back and forth. But on modern CPUs/networking hardware, that overhead is usually negligible, you may not even notice any delays. Years ago, that was not the case, but technology has evolved alot since the early days of the Internet, and now use of SSL/TLS is very commonplace, even recommended/required in many modern systems.
I built a web application with low traffic so far, after making some advertising I realized there are some suspicious requests against my server, this is what Loggly service shows me in panel:
Logs from Loggly about nginx requests
I am not an expert in security information buy I'm suspecting that someone wants to attack my site or are preparing a future attack.
What does these logs mean exactly?
Should I worry too much about this behavior?
are they using some exploit scanner software ?
I am setting a web application firewall to add some rules to DNS and changing all admin passwords but what other recommendation I must keep in mind?
Yep, some person or bot is using a vulnerability scanner to poke your server.
Unless it's excessive or causing stability issues, this is normal traffic. Every node that's accessible online will see attempts like this, and if you follow basic security practices (e.g. be up-to-date with os/app patches, use 2FA for logins, shut down unnecessary services/ports, vigilantly monitor your logs and usage, or at a bigger scale: invest in WAF, IPS/IDS products or use a vendor like Cloudflare), you shouldn't have much to worry about.
The culprit is Jorgee Security Scanner[1][2]
[1] https://www.checkpoint.com/defense/advisories/public/2016/cpai-2016-0214.html
[2] https://blog.paranoidpenguin.net/2017/04/jorgee-goes-on-a-rampage/
I'm developing an HTTP server in Go, but it doesn't seem to be able to prevent DDoS attacks. Do I need to implement a firewall for my server?
There's also another solution: I could use Nginx as proxy server to prevent DDoS attacks, but it will complicate server deployment.
Do I need to implement a firewall for my server?
OMG YES!
But it won't help much for DDOS. You need to be able to profile the attack and patch responses quickly for this. Using something like fail2ban make this much easier, but that you weren't sure if you needed a fiewall / if it would help with DDOS suggests that you may easily do more harm than good by trying to build adaptive defences, hence in your case I'd recommend not worrying about a DDOS until you get one / get a good hosting company who can provide network level services if such an attack occurs.
I don't think Nginx would be better or worse than your Go server. You still need a real firewall as well.
Anytime a username/password authentication is used, the common wisdom is to protect the transport of that data using encryption (SSL, HTTPS, etc). But that leaves the end points potentially vulnerable.
Realistically, which is at greater risk of intrusion?
Transport layer: Compromised via wireless packet sniffing, malicious wiretapping, etc.
Transport devices: Risks include ISPs and Internet backbone operators sniffing data.
End-user device: Vulnerable to spyware, key loggers, shoulder surfing, and so forth.
Remote server: Many uncontrollable vulnerabilities including malicious operators, break-ins resulting in stolen data, physically heisting servers, backups kept in insecure places, and much more.
My gut reaction is that although the transport layer is relatively easy to protect via SSL, the risks in the other areas are much, much greater, especially at the end points. For example, at home my computer connects directly to my router; from there it goes straight to my ISPs routers and onto the Internet. I would estimate the risks at the transport level (both software and hardware) at low to non-existant. But what security does the server I'm connected to have? Have they been hacked into? Is the operator collecting usernames and passwords, knowing that most people use the same information at other websites? Likewise, has my computer been compromised by malware? Those seem like much greater risks.
My question is this: should I be worried if a service I'm using or developing doesn't use SSL? Sure, it's a low-hanging fruit, but there are a lot more fruit up above.
By far the biggest target in network security is the Remote server. In the case of a Web Browser and an HTTP Server, the most common threats are in the form of XSS and XSRF. Remote Servers are juicy targets for other protocols as well because they often have an open port which is globally accessable.
XSS can be used to bypass the Same-Origin Policy. This can be used by a hacker to fire off xmlhttprequests to steal data from a remote server. XSS is wide spread and easy for hackers to find.
Cross-Site Request Forgeries (XSRF) can be used to change a the password for an account on a remote server. It can also be used to Hijack mail from your gmail account. Like XSS, this vulnerability type is also wide spread and easy to find.
The next biggest risk is the "Transport layer", but I'm not talking about TCP. Instead you should worry more about the other network layers. Such as OSI Layer 1, the Physical Layer such as 802.11b. Being able to sniff the wireless traffic at your local cafe can be incredibly fruitful if applications aren't properly using ssl. A good example is the Wall of Sheep. You should also worry about OSI Layer 2, the Data Link Layer, ARP spoofing can be used to sniff a switched wired network as if it where a wireless broadcast. OSI Layer 4 can be compromised with SSLStrip. Which can still be used to this day to undermine TLS/SSL used in HTTPS.
The next up is End-user device. Users are dirty, if you every come across one of these "Users" tell them to take a shower! No seriously, users are dirty because they have lots of: Spyware/Viruses/Bad Habits.
Last up is Transport devices. Don't get me wrong, this is an incredibly juicy target for any hacker. The problem is that serious vulnerabilities have been discovered in Cisco IOS and nothing has really happened. There hasn't been a major worm to affect any router. At the end of the day its unlikely that this part of your network will be directly compromised. Although, if a transport device is responsible for your security, as in the case of a hardware firewall, then mis-configurations can be devastating.
Let's not forgot things like:
leaving logged-in sessions unattended
writing passwords on stickies
The real risk is stupid users.
They leave their terminals open when they go to lunch.
Gullible in front of any service personell doing "service".
Storing passords and passphrases on notes next to the computer.
In great numbers someone someday will install the next Killer App (TM) which takes down the network.
Through users, any of the risks you mention can be accomplished trough social engineering.
Just because you think the other parts of your communications might be unsafe doesn't mean you shouldn't protect the bits that you can protect as best you can.
The things you can do are:
Protect your own end
give your message a good shot at
surviving the
internet, by wrapping it up warm.
try to make sure that the other end is not an impostor.
The transport is where more people can listen-in than at any other stage. (There could only be a maximum 2 or 3 people standing behind you while you type in your password, but dozens could be plugged into the same router, doing a man-in-the-middle attack, hundreds could be sniffing your wifi-packets)
If you don't encrypt your message then anyone along the way can get a copy.
If you're communicating with a malicious/negligent end-point, then you're in trouble no matter what security you use, you have to avoid that scenario (authenticate them to you as well as you to them (server-certs))
None of these problems have been solved, or anywhere close. But going out there naked is hardly the solution.