Tag Info

New answers tagged

0

Thank you all for your time to answer. Basically what I'm trying to do is to proxy the outgoing/originated traffic of the 2nd container (NOTE: I'm NOT trying to proxy the incoming traffic, so cannot use the Apache mod_proxy or Nginx proxy_pass. These modules works for incoming traffic). 1st container runs a proxy service on port 8080. As Thierno suggested I ...


1

As I don't see it in your shown documentation, I'm going to assume you forgot to enable IP forwarding. Run the following command to verify that this is indeed the case: sysctl net.ipv4.ip_forward If IP forwarding is indeed disabled you should see: net.ipv4.ip_forward = 0 If this is your problem, run: sysctl -w net.ipv4.ip_forward=1 Possibly your ...


1

I've got the same issue recently. Supposed to be is not a packets losing in fact, it have to be invalid packets I guess. One of ClusterIP howtos suggests just to filter them out. iptables -t mangle -I PREROUTING -m state --state INVALID -j DROP


0

I think that using the $http_proxy env var should help. You can set an entrypoint in your docker file (for the container #2) to export the env var when the container is starting. Somewhere in your entrypoint, you should have something like this: export http_proxy=http://$CONATAINER1_PORT_8080_TCP_ADDR:$CONATAINER1_PORT_8080_TCP_PORT I don't know exactly ...


1

The suggested solution is lacking (or smart) in the sense that it does not save IPTABLES so the changes made to IPTABLES will be lost on next boot. You should save your blocked IPs by committing them: /sbin/service iptables save CHANGE done /sbin/service iptables save rm .ips On the other hand, since the system is an automation, maybe it is wise to only ...


0

Did you change your routing table? You need to add route to gateway with src 192.168.1.2, maybe. You can look at routing table using iproute2: ip route If you have something like that: default via 192.168.1.254 dev eth1 you add a route to this address: ip route add 192.168.1.254 dev eth1 src 192.168.1.2 or you can add route to subnet: ip route add ...


0

All the configuration files for csf are in /etc/csf and include: csf.conf - the main configuration file, it has helpful comments explaining what each option does csf.allow - a list of IP's and CIDR addresses that should always be allowed through the firewall csf.deny - a list of IP's and CIDR addresses that should never be ...


0

Dave, can you provide more information? Are you wanting to simulate a network condition to cause a TX/RX Drop value on a switch port? One common cause of a TX/RX Drop value climbing is incorrect speed and duplex settings on the point to point ports. If one port is set to 100 Full, but the other is set to 10 Half, you will have packets dropped ...


0

Maybe you can use libvirt's hook script. You script a shell script that libvirt will execute as soon as your VM is started. Create the file /etc/libvirt/hooks/qemu with this inside: #!/bin/bash if [ "${1}" = "<the name of your vm>" ] ; then VM_NAME=${1} VM_IP=172.16.20.10 if [ "${2}" = "prepare" ] ; then iptables -t ...


0

IF you are able to connect to your VPN Server than you are most likely setup correctly for server/client to talk. The issue then becomes one of IP and routing. I usually use pfsense for my openvpn server rather than using the conf file but the effect should be the same. Every time I've used openvpn, I have never gotten a connection on x.x.x.2 and can ping ...


2

If you change the default policy to DROP then you need to allow the traffic to come back from 192.168.1.2:22 through the firewall. $IPT -A FORWARD -j ACCEPT -m conntrack --ctstate ESTABLISHED $IPT -A FORWARD -j ACCEPT -p tcp -d 192.168.1.2 --dport 22 It may also be necessary to allow reverse DNS lookups by adding : $IPT -A FORWARD -j ACCEPT -p udp -s ...


1

I figured out the problem. Using the Ruby Sinatra framework, I had to specify the IP address to bind to in the application code, otherwise the HTTP server only listens to calls to localhost.


1

You can leave the default policy as is and simply add $IPT -A FORWARD -j DROP to the end of the script to effectively drop anything that wasn't previously matched.


0

The issue is that as your containers are on the same network then the traffic is seen from 172.17.0.6 as the following : Request to 172.17.0.4 port 80 Reply from 172.17.0.4 port 8080 Thus it appears as two different TCP conversations. The reason for this is simple : you try to DNAT inside the second container but you don't un-DNAT (SNAT) as the ...


0

Reciprocal linking isn't something docker has, so far as I know ( info revealed at run time about a container back ported or reciprocated to a progenitor). That's probably why most tutorials have a third, common ancestor, 'proxy' being used. If you're willing to use frameworks like fig or weave, that I believe have yaml or json configuration files, you'd ...


3

I think you meant something like this: sudo iptables -A INPUT -p udp --dport 1194 -j ACCEPT


1

Sounds like you're looking for something called a "Captive Portal" feature. If your router doesn't come with one out of the box, you have 2 options: Get a router that does come with the feature, or Depending on your router's model, flash it with custom firmware, like Tomato or DD-WRT Please note that option #2 requires quite a bit of work, depends on ...


0

iptables -A INPUT -i eth1 -m iprange --src-range 10.50.10.20-80 -j ACCEPT May give the following error: iptables: Applying firewall rules: xt_iprange: range 10.50.10.20-80 is reversed and will never match To correct this just put the full ip instead like this: iptables -A INPUT -i eth1 -m iprange --src-range 10.50.10.20-10.50.10.80 -j ACCEPT ...


6

IIRC iptables rules are order dependent: if the first rule matches, it won't parse any more. Reverse the order and you should achieve what you're trying to do. Extension: it is not always so, some rules (f.e. -j LOG) allows the packet processing to go further. But the common ACCEPT, REJECT, etc. rules aren't. Best if you see iptables as if it were a ...


0

So I followed Michael Hampton hint, I created a vm using KVM and I added the following iptables rules iptables -t nat -I PREROUTING -p tcp -d 1.2.3.4 --dport 3389 -j DNAT --to-destination 192.168.122.1:3389 iptables -t nat -I PREROUTING -p udp -d 1.2.3.4 --dport 3389 -j DNAT --to-destination 192.168.122.1:3389 iptables -I FORWARD -m state -d 192.168.122.1 ...


3

If you want your Windows server to act as a router, you'll need to install and configure the Routing and Remote Access Server role; otherwise, the server will be able to talk to both networks, but will not forward traffic between them. Once the role is installed, you only need to enable "LAN and WAN routing"; there is no need for other features like VPN or ...


0

You quote the port range "1024-1048" in your existing config. Are you implying that you've restricted your FTP server to only use these ports for data connections ? If so, what you've done should work. Check your machine is set to route packets by doing: cat /proc/sys/net/ipv4/ip_forward You should get a "1" back if forwarding is enabled, which will ...


0

You don't give enough detail about what you're trying to achieve or your network setup for me to be able to give a detailed answer. If you want to bridge two networks your OpenVPN instance needs to create a tap interface, not a tun. You can then use the standard linux brctl utility to bridge eth0 and tap0 (or whatever interface name you choose). You ...


0

Personally I would rate limit only for specific TCP packets (syn flood, scans of various types, etc) with iptables and use nginx to rate limit HTTP requests per time interval behind this. Keep in mind that browsers open multiple TCP connections for a single actual user so rate limiting to 50 connections per minute once the burst is reached is dramatically ...


0

Try using REDIRECT of iptables. iptables -t nat -I PREROUTING -d <public ip> -p tcp --dport 54321 -j REDIRECT --to-port 12345 If you need udp, just change the protocol.


1

Ports 137 and 138 should be opened for UDP traffic instead of TCP: -A RH-Firewall-1-INPUT -s 192.168.168.0/24 -m state --state NEW -p udp --dport 137 -j ACCEPT -A RH-Firewall-1-INPUT -s 192.168.168.0/24 -m state --state NEW -p udp --dport 138 -j ACCEPT -A RH-Firewall-1-INPUT -s 192.168.168.0/24 -m state --state NEW -p tcp --dport 139 -j ACCEPT -A ...


0

Your br0 should be the gateway of your container. Check about lxc.network.ipv4 syntax too. Maybe you should put subnet mask.


0

Just before reject rule in RH-Firewall-1-INPUT chain, add a rule that logs all traffic. It could help identify what packages are being blocked: -A RH-firewall-1-INPUT -j LOG


-1

oops i misread the question.... this may be closer to what your looking for? filter on outbound traffic? iptables -P OUTPUT DROP iptables -P INPUT ACCEPT for x in $(cat list.of.allowed.websites.txt); do for i in $(dig $x +short | cut -d\ -f[theip]); do iptables -A OUTPUT -d $i/32 -j ACCEPT; done; done allow all the usual outgoing... ntp, ...


0

Yes, you need ebtables to apply netfilter rules on a bridge. The match rule is ip with parameters --ip-source-port and --ip-destination-port. You'd configure ebtables to allow the traffic you want, then an explicit drop for any other traffic. The DHCP client port is UDP 68, the DHCP server port is UDP 67. I believe the correct command syntax and order ...


2

If it were actually listening on 127.0.0.1 then it would be a service available only on the loopback interface, which cannot be reached from the outside. More likely it's listening on 0.0.0.0 (all interfaces) and that's what you want to prevent. In general, talking about "connecting to 127.0.0.1" doesn't make sense. Your service will never be addressable as ...


0

You also may find your list in /proc/net/xt_recent depending on your linux distro and version.


5

You could create a firewall rule to block this traffic, but it's much easier to enable reverse-path filtering instead. (root)$ echo 1 > /proc/sys/net/ipv4/conf/eth0/rp_filter Reverse-path filtering uses routing tables to filter out spoofed addresses on incoming packets. You can enable this by default on all interfaces by adding the following to ...


20

It is not generally possible to access services, bound only to localhost, from external addresses. SF is fairly replete with questions asking how to reverse that state of affairs, and the calisthenics required to do it are non-trivial, precisely because the whole concept of binding only to localhost is designed to give you that security without more ado.


0

Well I feel sheepish. The firewall rules work OK, but port 80 was being blocked at the ISP.


0

¿ can do this with amazon ec2 ? Si. You'll just need to make sure that source/destination checks are disabled for that EC2 instace.


3

The easiest way to find which rule to delete is to check the output of iptables-save, and change -A to -D is the rule you want to remove. In your case : $ iptables-save | grep 10.10.0.20 .... -A tcp_inbound -s 10.10.0.20/32 -p tcp -m tcp --dport 25 -j ACCEPT .... So you just need to issue : iptables -D tcp_inbound -s 10.10.0.20/32 -p tcp -m tcp --dport ...


8

You're trying to delete rule 2 of chain INPUT, where your rule is stored in chain "tcp_inbound"


1

iptables -A INPUT -p tcp -s 10.8.0.0/16 -d 192.168.X.X --dport 80 -j ACCEPT Should do the trick... unless you are nat-ing first. You could even add a -i tun0 or something, to limit on the interface name.


0

I guess that you are not removing your former iptables rule redirecting the traffic to port 9040, thus the new rule is not really affected, because the older rule is first. Examine you configuration: iptables -t nat -L I assume that the rule redirecting to port 9040 is first than the new you've added redirecting to port 8118, thus this late rule has no ...


0

The match extensions (-m) will definitely always have the same order, because the rule pattern you show: -A CHAIN1 -m mod1 -m mod2 -j CHAIN may not have the same meaning and may not have the same behavior as -A CHAIN1 -m mod2 -m mod1 -j CHAIN2 For the parameters of each match extension (I mean the param in : -m matchext1 --param1 val1 --param2 val2), ...


0

Rebooting the whole system or restart TeamSpeak solved the problem.


0

From man iptables: -j, --jump target This specifies the target of the rule; i.e., what to do if the packet matches it. The target can be...one of the special builtin targets which decide the fate of the packet immediately and ACCEPT means to let the packet through. Logging always helps for understanding the flow. Try: iptables -A INPUT -j LOG. If ...


2

Consider using iptables TEE target. For example: -t mangle -A PREROUTING -i eth0 -j TEE --gateway <your IDS IP> More information here and/or here


0

It is very easy with port mirroring. However it needs expensive switches like cisco.


2

The firewall won't block already established VPN connections because you have the following rule near the top: -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT That means, connections already in the ESTABLISHED state (from the point of view of the conntrack module of netfilter) will keep passing through. Plus, most likely your INPUT chain has a ...


4

Check on MASQUERADE target instead of SNAT : it supports the option : --to-ports port[-port] This specifies a range of source ports to use, overriding the default SNAT source port-selection heuristics (see above). This is only valid if the rule also specifies one of the following protocols: tcp, ...


0

I do not think you can control which ports are used for which NAT'd ip's. However if you have any extra IP's in public space you could have take advantage of that by mapping the ones you want to keep track of: iptables -t nat -A POSTROUTING -s 10.8.0.10/32 -o venet0 -j SNAT --to-source 1.2.3.1 iptables -t nat -A POSTROUTING -s 10.8.0.20/32 -o venet0 -j ...


1

The trick involves enabling localhost/localnet route processing for your outbound interface with: sysctl -w net.ipv4.conf.all.route_localnet=1 Then this works: iptables -t nat -A OUTPUT -m addrtype --src-type LOCAL --dst-type LOCAL -p tcp --dport 8888 -j DNAT --to-destination 10.0.3.10 iptables -t nat -A POSTROUTING -m addrtype --src-type LOCAL ...


1

miniBill is right: you have indeed mixed up sport and dport. When you write: iptables -A INPUT -i eth0 -p tcp --sport 2222 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -o eth0 -p tcp --dport 2222 -m state --state NEW,ESTABLISHED -j ACCEPT Your INPUT ssh traffic is to your server, so that should have destination port 2222, not source ...



Top 50 recent answers are included