I'm learning networking and internet security, and I'm trying a perform a Denial-of-Service attack on a VM(ip-address:192.168.100.1) who act as a gateway.
Following some tutorials,I'm using hping3 to perform this with hping3 -S --flood -V -p 80 192.168.100.1 as command.
Still I'm able to ping to the gateway from another host.
I've tried to add another attacker,and open more terminals,still no success, the one thing I have obtained is an increment of the round-trip-time ( about 90ms).
Are the attackers too few to perform this?
DOS may be illegal (in many countries). I write this just for educational purpose
Yes you will need more attacker instances. It is highly unlikely that the attacker has a single machine with a big enough Internet connection to generate enough traffic on its own. One way to generate that much traffic is through a botnet.
You may refer to the following link as the 1st step:
https://blog.cloudflare.com/65gbps-ddos-no-problem/
Related
I'm trying to think through the advantages and disadvantages of haproxy health checks happening on a different port from regular traffic.
If a server becomes overloaded having health checks on a different port may mark the server as being up even when overloaded. I think this is a good thing because taking servers offline may make an overloading problem worse, but want to confirm that that makes sense. I can't seem to find any good docs on the tradeoffs though and was wondering if someone has a good analysis on the tradeoffs.
The port keyword is often used with address to send health checks somewhere else than directly to the service you are checking. One example might be enabling option httpchk to monitor a non-HTTP service. What you then do is have a HTTP-compatible service that when queried can execute complex health checks against the service you are actually testing.
The above is often done with agent-check nowdays, but some people prefer to use an HTTP interface.
This also has nothing to do with server load, the only idea is to send health checks to some other service, not the one directly monitored, which is more capable of testing the actual service (possibly by using a more-complex logic) and returning a result. As an example, one could have a MySQL backend which instead of being tested just for authentication by option mysql-check, could be tested by a PHP script that, for example, checks if backup is running and if it is returns a 5xx HTTP error. The configuration could be something like:
backend mysql
mode tcp
option httpchk GET /mysql-status.php
server mysqlserver 10.0.0.1:3306 check port 80
I am setting up two computers to run a web application. web-host hosts a MongoDB database and NodeJS web server, while worker runs some more demanding processes and populates the database. Using an SSH tunnel from worker, web-host:27017 is accessible using localhost:9999 from worker. web-host:80 has been set up to be accessible on http://our.corporate.site/my_site/.
At the moment MongoDB has no authentication on it - anything that can contact web-host:27017 can read or write anything to the database.
With this setup, how paranoid should I be about authenticating requests to MongoDB? The answers to this question seemed to suggest not very. Considering access is only possible from localhost it seems about as secure as the local file system. In MySQL I usually have a special 'web' user with limited privileges to limit the damage of an injection attack in case I make a mistake sanitizing input, however MongoDB seems less vulnerable to injection (or at least easier to sanitize) compared with MySQL.
Here's the issue: If you do set-up Mongo authentication, you are going to need to store the keys on the machine that accesses it.
So assuming that web-host:80 is compromised, the keys are also vulnerable.
There are some mitigation processes you can use to secure your environment, but there is no silver bullet if an attacker gains root access to your environment.
First I would consider putting mongodb on a separate machine on a private internal network that can only be accessed by machines in a DMZ (the part of the network where machines can communicate with your internal network and the outside world).
Next, assuming you are running a Linux-based system, you should be able to use AppArmor or SELinux to limit which processes are allowed to make outbound network requests. In this case only your webapp process should be able to initiate network requests such as connecting to your Mongo database.
If an attacker was able to get non-root access on your machine, the SELinux/AppArmor system policy would prevent them from initiating a connection to your database from their own script.
Using this architecture, you should be more secure than simply augmenting your current architecture with authentication. In a choice between the SELinux/AppArmor, I would use SELinux, since it is was much more mature and had much more granular control the last time I checked.
After Enable telnet service in Windows XP PRO SP2, how affect the security level of system?
Will it be easier to infected virus or worm attack?
First and foremost if you need remote access you should always consider SSH over telnet in almost every situation. If you can't because of automated robots connecting over telnet only then you have to live with that, but other than that you should always use SSH.
By enabling telnet service you've provided yet another vector of attack for outside attackers. Telnet has to known weakness because of the way it's architected, but there could be implementation defects specific to the windows service that could allow attackers to gain access. You'll need to do some research to figure out what vulns exist on the telnet service for windows.
SP2 is pretty old so you'll want to apply all security patches so you're up to the latest. Not doing so could allow an attacker thru another vector whether you're running telnet service or not. In the big picture this question only makes sense to ask after you've upgraded your machine to the latest security patches. Does turning on telnet service expose you to any known vulnerabilities for which a patch doesn't exist? That would have to be researched.
Now there are some concerns you should have about using telnet. One telnet doesn't encrypt passwords so if someone were to get behind your firewall they could potentially sniff the traffic going to that machine and get the root password because telnet sends passwords in the clear. That could mean any computer on your network could see admin passwords. Telnet should not be accessible to the internet because of this. You should also be very careful about wifi access as well. Make sure you are using WPA or some sort of protection from random people connecting into your network. Otherwise anyone could see your passwords in the clear just by driving by. So I'll assume telnet is turned on and is behind a firewall or VPN, not accessible to a public wifi. If that's the case the potential threats are much lower since telnet can't be reached but by someone with access to your internal network. At this point you've lowered your exposure to just the people who have access to that network. That means how well does your VPN/firewall protect you? If your telnet port is open on the firewall then you're not protected. But, if it's safely behind one or both of those you could get away with running it. But bear in mind that your security is hinging on the security of your firewall/VPN in that case.
I need to develop a server side application that opens sockets and manages communication with multiple clients. Previous answers have told me this is possible using a single script file, which loops forever.
Is this possible using only a PHP/Perl/Python hosting service? or would I need a VPS or shell access?
Any help is appreciated since I've never worked with sockets before. Thanks for your time.
Cheap Perl/PHP hosting services don't want you running your own long-running processes.
This means you will need a VPS (which obviously includes shell account since you can do anything you want on your private server). A few VPS providers might block outgoing IRC port but I think that is rare.
Linode and Slicehost/Rackspace are just two examples very very well run VPS service providers and I guarantee you can run your own socket application on them.
It would make your host very unhappy since their CPU time is valuable! If you use shared hosting, your host might just kick you out for such a solution! (Read your contract for the fine details.)
I think it could be possible but it depends on the setup of your host, plus the permissions your host are granting you. And most will be unhappy about anything that runs forever. (They prefer to see just short, simple applications.)
Usually the service firewall will block any unexpected ports, or if they are not doing it now they will start doing it after they figure out what you are doing and decide they don't like it.
I would say no because it involve too much security problems
I have a Perl-based CGI/Fast CGI web service and want to rate-limit clients by IP address to stop aggressive clients causing too much work.
I have looked around for some code and found Algorithm::TokenBucket in CPAN but that is for client requests; it has no persistence and has no per-user config so is not really useful for server-side rate limiting.
I am looking for suggestions for something that already exists, otherwise I'll need to roll my own based on some simple persistence such as tie to DB_File per-IP address and some batch job that does the token management.
I've used Cache::FastMmap for rate-limiting by tracking hits per IP address. It's a cache so data will expire over time, but if you set the size and expire time right, this shouldn't be an issue.
The IP address is the hash key and the hash value is an array of timestamps. I have a second data structure (also backed by Cache::FastMMap) which is a hash of banned IP addresses, updated according to the data from the first structure.
I know it's not what you asked, but have you considered handling this elsewhere in the stack where it's already been done for you? Clearly I don't know your deployment stack, but if it's apache you could use mod_evasive. Alternately if you're on Linux you could let iptables do its job using something like:
#Allow only 12 connections per IP
/sbin/iptables -A INPUT -p tcp --dport 80 -m conn-limit --connlimit-above 12 -j REJECT --reject-with tcp-reset
certainly more complicated rules are possible.