Tag Info

Hot answers tagged

3

The correct way to do this is to add a profile for SNMP to firewalld. Using UDP 161 not TCP vim /etc/firewalld/services/snmp.xml <?xml version="1.0" encoding="utf-8"?> <service> <short>SNMP</short> <description>SNMP protocol</description> <port protocol="udp" port="161"/> </service> Then you should ...


2

You would want to add this to the iptables in order to block an IP: iptables -A INPUT -s <ipaddress> -j DROP Per the man pages: DROP means to drop the packet on the floor.


2

The second configuration will not work (try it!). Since your default policy is DROP on the OUTPUT chain, the third packet of the TCP three-way-handshake will be blocked by the firewall, as that one does not fall under NEW, so the connection will never be established. It would work if your default OUTPUT policy would be ACCEPT, or you had some other OUTPUT ...


2

You would need policy routing to set up routing tables for each specific traffic. I've found a concise and good example in Linux Advanced Routing Mini HOWTO. Put the following line in /etc/iproute2/rt_tables: 1 DIRECT Then you can do like: iptables -t mangle -A PREROUTING -p tcp --dport 900:999 -j MARK --set-mark 1 ip route add default via <gateway ...


2

There has been no release of iptables with cgroup support so far. Latest iptables is 1.4.21, which was released back in Nov 2013 (afaik). Cgroups support was added later, and never released officially. That's probably the reason there is no new iptables in vast majority of distributives (including e.g. Arch).


2

specific versions of OpenWRT have a performance optimization enabled. This turns it off: sysctl -w net.netfilter.nf_conntrack_skip_filter=0 http://wiki.openwrt.org/doc/uci/firewall#nf_conntrack_skip_filter


1

The problem with blocking on IP is the person on the attacking end will just move to another IP, if they're intent on attacking your IP. The fail2ban facility is extremely effective at blocking IPs, so IPs block for certain periods of time + then unblock. This ensures if you incorrectly block an IP by accident, it will eventually unblock. Using fail2ban ...


1

Seems you need to (cross) compile a new kernel.


1

you are not adding rule for NEW , RELATED,ESTABLISHED . in previous version it may be it was allowing by default without adding or you have added. in this case you have to add rule . first delete all rule using : iptables -F iptables -X then add rule : iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A INPUT -m state --state NEW ...


1

Remember that the route only affects outgoing outgoing traffic, not return traffic. So possibly your route is being respected, but the particular router you are talking to is replying from a different address. If that is not the case, then to debug the problem further I would recommend first running ip route get 192.168.5.1 or whatever address you are ...


1

iptables comes with the utilities which might be useful to update iptables configuration safely: iptables-save,iptables-restore, iptables-apply. To temporarily change and test running configuration, you could do like this: $ sudo iptables-save > rules.v4 $ vi rules.v4 $ sudo iptables-restore < rules.v4 If you want to change configuration on remote ...



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