Tag Info

Hot answers tagged

7

You can use the service iptables save command.


6

You can run /etc/init.d/iptables save. This will write out the file /etc/sysconfig/iptables. Look at that file to verify that the contents has the rules that you want (it won't be in same format as iptables run from the command line, but you should be able to get the gist of it). Make sure that iptables is set to run on reboot. Run chkconfig --list ...


4

Your password has 12 characters, which at 6 bits per character is 72 bits of randomness. An SSH key is at least 2048 bits, which is a lot more to try to guess. An SSH key is stored on your client, only accessed by the SSH client, and not even known by you. A password is often used for other purposes (higher chance of leakage) and typed into untrusted ...


4

running iptables -L -n does not give you the interface names the rules might have defined as conditions. Rules that look alike with different targets are probably conditioned for different interfaces unless they have been written a) in a hurry b) by an absent-minded admin c) as a temporary workaround for something or d) all of the above Use iptables ...


4

We use fail2ban It automatically blocks the IP of the spambot or malicious user for a user defined period of time once it detects a user defined number of requests to non-existent pages, failed login attempts etc. We currently use it to protect against ssh attacks but are now extending it to our website.


3

You should not rely on blocking specific IP addresses to mitigate hacking attempts. To make your system secure, it should be protected against hacking from ANY IP address. You should block access to all ports except for the ports which are used. For example, when you provide a web service, allow port 80, and only allow it to communicate directly with a web ...


3

You don't really seem to have the GRE protocol enabled, from what I can see. You have port 47 TCP allowed, but that's not the same. Your rc.local rules regarding GRE seem fine but are probably being overwritten, so add those rules in your firewall system proper. You also have a DROP policy for forwarding packets - add this rule as a mininum: iptables -A ...


3

On a lot of consumer internet networks, I can just set my IP to that of the neighbors and have their IP, so yeah, IP's can be spoofed. Colocated servers also often share one subnet among different customers. Just DOS the machine so it goes down, take over its IP and you're done... Anyway, it depends on your situation. Do you have data which you expect to be ...


3

CSF will consider any hits to ports not whitelisted in csf.cfg's TCP_IN setting to be a port scanning attempt. Since 10000 is a legitimate port for you, add it to the list in TCP_IN and TCP_OUT and you'll be good to go.


2

Iptables could be used to that end. Blocking parallell connections: iptables -A INPUT -p tcp --syn --dport 80 -m connlimit \ --connlimit-above 20 -j REJECT --reject-with tcp-reset Blocking floods (block more than 10 connections per minute) : iptables -A INPUT -p tcp --dport 80 -i eth0 -m state --state NEW -m recent --set iptables -A INPUT -p tcp ...


2

You need to install libwww-perl. sudo aptitude install libwww-perl OR sudo perl -MCPAN -e 'install Bundle::LWP' OR wget http://search.cpan.org/CPAN/authors/id/G/GA/GAAS/libwww-perl-6.04.tar.gz tar xzf libwww-perl-6.04.tar.gz cd libwww-perl-6.04 perl Makefile.PL make sudo make install


2

this means it has blocked the following 3 ip's for the respective reasons 81.4.153.90 connecting to port 4899 on tcp 82.178.69.36 connecting to port 80 via UDP 82.178.182.44 connecting to port 80 via UDP from my knowledge a webserver doesnt run on UDP ports hence why your firewall will block UDP 80 these are blocked because CSF will generally block IP's ...


2

You need allow DHCP requests: $IPTABLES -I INPUT -i $LAN_IFACE -p udp --dport 67:68 --sport 67:68 -j ACCEPT in CSF you can set 67 and 68 in UDP_IN, UDP_OUT and unset DROP_NOLOG(CSF Firewall Configuration)


2

I don't think you can do that but you can use an Include statement in your /etc/csf/csf.deny file Include /etc/csf/csf.denytoo Perhaps you can use that to help organise your blocked IP addresses ?


2

netstat is returning connections like this: udp 0 0 :::57817 :::* which, if piped into "cut -d: f1", will return a blank line. that said, and apologies if this seems condecending, how do you know that you're being DDoS'd?


2

My personal favorite of understanding iptables rulesets is the command iptables-save, which dump all rules to stdout. This helps to get the idea of the right order of rules. A full picture of packet traversal in iptables is here: http://www.frozentux.net/iptables-tutorial/images/tables_traverse.jpg


2

If memory serves, /etc/sysconfig/iptables-config is the file that describes what options are used when the rhel iptables init script is brought up. It does not have explicit rules in it. the /etc/sysconfig/iptables file on the other hand does have these rules in it. It is formatted per the output of the iptables-save command; in fact, when you run service ...


1

Actually, you do not want to open port 11211 in your firewall. In your setup, memcached is running on the same machine, and localhost is rarely or never firewalled from itself since this causes the universe to implode. Thus processes on the same machine can talk to each other (e.g. PHP to memcached) without any other special firewall rules. But, until very ...


1

Add cmd:/usr/sbin/apache2 -k start to csf.pignore file and restart CSF and LFD (you might need to kill the lfd process)


1

Congratulations, under the influence of slow and patient questioning you've solved your own problem. Rule 13 in the ALLOWIN chain is allowing all traffic from the IP address of your test client (59.189.154.164), so when you started an MTA the nmap response went from filtered (ie, you can get to the port, but there's no listener, so you get a TCP reset) to ...


1

First, get a list of what your current rules are: iptables -L -v E.g Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 38M 26G ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED 489 47582 ACCEPT icmp -- ...


1

Bastille deals with the configuration of the server itself. It helps you harden services/operating system. It doesn't actually touch the firewall, so it should have no conflicts with CSF.


1

Yes. csf.allow actually talks about this, and you need to add their IP to csf.ignore to prevnt it.


1

CSF can do country blocks itself, from the config file: ############################################################################## # SECTION:Country Code Lists and Settings ############################################################################### # Country Code to CIDR allow/deny. In the following two options you can allow # or deny whole country ...


1

Keeping your HN's system up to date and correctly configuring its firewalling rules should suffice. I recommend using Shorewall instead of bare iptables because it's so much easier to read (and hence easier to keep well configured). There's specific documentation for configuring Shorewall when OpenVZ is present. Also remember to configure sshd in order to ...


1

Configuring firewall in the HW node is tricky as you have to consider all the traffic going through the node from/to your VPSs before enabling the firewall in HW node. You may need to do an audit and configure the firewall accordingly, if you are going to use one in the main node. Normally, DCs will use hardware firewall to protect the nodes from attacks to ...


1

Hard to say since you're not displaying for which chains these rules apply. Easily said: For a firewall you've got to start with the FORWARD chain and follow all rules that match in sequence until you hit an ACCEPT, DROP or REJECT If you reach the end of all rules this way, the FORWARD's default policy applies.


1

grep an IP which you belevie it is blocked in /etc/csf/ grep IP /etc/csf/* -irl


1

According to this http://configserver.com/free/csf/readme.txt You can just do it! You can also include comments when using the csf -a or csf -d commands, but in those cases you must not use a # like this: csf -d 11.22.33.44 Added because I don't like them


1

Check out this question over on security stack exchange - lots of useful answers.



Only top voted, non community-wiki answers of a minimum length are eligible