Hot answers tagged

5

As OEL 6 using iptables; Allow ICMP traffic to leave your server, ie so you can ping out $ iptables -A OUTPUT -p icmp -o eth0 -j ACCEPT Then block IMCP replies: $ iptables -A INPUT -p icmp --icmp-type echo-reply -j DROP $ iptables -A INPUT -p icmp --icmp-type echo-request -j DROP SSH would be the same, assuming SSH is on port 22. $ iptables -A ...


5

On Linux-based platforms there is a netlink socket that you can open from your Java program and determine whether or not to accept the packet. This socket can be included in the network stack with an iptables rule. Here of course you can also limit the types of packets to be passed to your usermode filter. Here's what the man page has to say on the matter: ...


4

On OpenBSD the divert(4) mechanism can be used to lob packets between the kernel and an arbitrary userland process written in an arbitrary language, assuming the language can be made to interface with the system call (either directly or possibly via the additional complication of a shim divert(4)-to-whatever-IPC-is-required proxy layer should the language ...


2

It's entirely plausible that a firewall could be built in Java, but It's very unlikely to be a tidy project that runs at the speeds that network systems require. I used to work for a company that made a network security appliance that ran on top of SecureBSD. Any changes that we made to ipchains needed to be carefully scrutinized because the traffic was ...


2

The problem here is that /etc/rc.d/pf runs before /usr/local/etc/rc.d/ezjail, so the kernel hasn't configured the jailed network by the time it tries to load the firewall rules. You might be tempted to alter the pf script to start after ezjail, but that's not a good idea - you want your firewall to start early in the boot process, but jails get started quite ...


1

There is no 100% certain way of knowing a network communication failure is being caused by a firewall, but by going with the rule of elimination, you can come to this conclusion. Make sure you are not running any server based firewalls, likes of iptables. Because, if you go to firewall people, they will blame those first, most of the time without doing ...


1

The rules in /etc/sysconfig/iptables are loaded when the iptables service is started. Since your firewall chains appear empty, there's probably nothing in there. Do not that there could rules set like the nat and raw tables. If you change the rules directly in /etc/sysconfig/iptables, you need to restart the iptables service and inversely if you add rules ...


1

In the end the solution was to run the following command: firewall-cmd --zone=FedoraServer --add-port=3000/tcp Seems that on Fedora 24, or the Fedora 24 as set up on linodes perhaps, iptables doesn't have a TCP entry.



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