Tag Info

Hot answers tagged

12

So I found out a way to do this. I'm not sure if it's the preferred way but it works! At your favourite shell: sudo ifconfig lo0 10.0.0.1 alias sudo ipfw add fwd 127.0.0.1,9090 tcp from me to 10.0.0.1 dst-port 80 (The alias to lo0 seems to be the missing part) If you'd like a (fake) domain to point to this new alias then make sure /etc/hosts contains the ...


6

You're doing two things there. Enabling IP forwarding. The OS X equivalent might be: sysctl -w net.inet.ip.forwarding=1 ...but since I don't know exactly what you're trying to do, this might be technically correct but unhelpful. Adding a largely unnecessary firewall rule. If you haven't changed the default policy for your FORWARD chain (iptables -P ...


4

Correct rules need to be reestablished every reboot. It will not directly affect other rules, but can indirectly (for instance, if another rule allowed the IP for whatever reason, this might block the IP...) You're looking for the ever popular fail2ban, which reads logs files and bans IPs of people doing "bad" things. Also, you don't really want too keep ...


4

Globally blocking all traffic to the specified port seems to be more effective than blocking certain kinds of traffic, as you said less packet inspection. It really depends on your intent. If you want the service to be open and available but don't want someone SYN scanning that port, there are other methods of detecting this kind of activity. If you don't ...


3

In order of preference: My first suggestion would be to upgrade these machines to a supported version of FreeBSD. 4.x is pretty well ancient at this point, well beyond the end of support life, and you would do better replacing it than trying to keep it alive. You can also secure the new machines according to current best practices. Note that there is no ...


2

This worked well for me: Enable firewall via System Preferences Create ipfw startup file as described here: http://serverfault.com/a/235124/94860 Add the following line to the startup file, as described here: http://blog.xeiam.com/blog/2013/06/27/port-forwarding-80-to-8080-for-tomcat-using-ipfw-on-mac-osx/ add 100 fwd 127.0.0.1,8080 tcp from any to any 80 ...


2

A combination of blockhosts and mod_evasive have always worked very well for me, though once you have closed up all the holes, the spurious connections should drop off pretty rapidly. Changing IP may help, but may not be worth the effort if it's a public address since many of your attacks are possibly pointed at the name rather than the ip address.


2

The files hosts.allow and hosts.deny are, so to say, deprecated. They are mainly used for tcp-wrapper and maybe used by other services or applications. But if they are used depends on the implementation of the program. Using a firewall is the preferred method because their rules are based on IPs, ports and other criteria. The firewall is independent of the ...


2

Well, you're asking for two different things here. Certainly the "easiest" thing to do would be to use Apple's built-in GUI. For most things that should be sufficient, as long as you're doing ingress filtering and just want to open up a few services it should be more than enough. If you want more control, I think ipfw is certainly worth the time investment. ...


2

No, in OpenBSD v4.6 version, PF has no divert-like feature. But good news, divert for PF will be included in OpenBSD v4.7 version See http://www.mail-archive.com/source-changes@openbsd.org/msg11694.html for details. You could try it with OpenBSD-current branch / snapshots.


2

Got it! I'm not sure if it's a bug in Snow Leopard, or some new security feature. But someone posted to the sshuttle mailing list the fix to the problem, which is simply this: sysctl -w net.inet.ip.scopedroute=0 Running that command makes the above set of commands (in the question posted above) work correctly as it did in MacOS 10.5. Thus, transparent ...


2

Imagine trying to drive exactly 55 miles per hour if you had a one second delay between when you pressed on the accelerator and when the car went faster. You'd have a pretty hard time doing it. And you would at least have the advantage that you know you need to drive 55 miles per hour. Now, imagine you don't know that. So what happens is when you go over 55 ...


2

It's my untested theory that dropping all packets to a port is faster than dropping just the syn packets. Here's why: Unexpected packets may normally generate a TCP reset or ICMP port unreachable message. Only writing a rule for SYN packets will cause other packets to trigger into the OS. The rule still has to be matched against. Both rules are checking ...


2

Your server most likely did not freeze, it was unreachable. The default rule for ipfw is to deny everything. You can recompile the kernel with " options IPFIREWALL_DEFAULT_TO_ACCEPT" set, or add ";ipfw add allow all " to your command (or build a script that flushes and adds your rules at once).


2

You can do it with PF as well. However, rdr only accepts incoming packets. Thus, you have to first route those packets to lo0, then add a rdr rule there (which will catch them as they will be routed in from "somewhere") to send them to your local ssh server. The order is necessarily rdr stuff, then filter stuff (like pass), but chronologically the 2nd rule ...


2

You have enabled the IPv6 Firewall without configuring it,so it is defaulting to type "unknown". Either disable the IPv6 firewall by removing ipv6_firewall_enable="YES", or configure rules for the IPv6 firewall and load them as you are with the IPv4 firewall. Edit: The above is true for previous versions of FreeBSD. As of 9.0-STABLE the IPv6 and IPv4 ...


2

I'm coming a little late to answer your question. Your ipfw solution should work, but not as you wrote the rule and, as you don't give a lot information about your configuration, I suppose that you missed a few things : did you set scopedroute to 0 (using sysctl) did you set forwarding to 1 (using sysctl) did you activate the firewall do you nat between ...


2

The solution should have been obvious from the problem that the address translation was always occurring before state rules were checked. The address translation needs to be split. The corrected version of the rules found above is: add 00050 divert natd ip4 from any to any via wan0 in add 00060 check-state # Talking to myself add 00200 allow ip from me to ...


1

#!/bin/sh # latency.sh oif="em0" # just the interface looking to the outer space # let's create two seperate pipes ipfw pipe 1 config delay 10000ms bw 1Kbit/s ipfw pipe 2 config delay 10000ms bw 1Kbit/s # let's pipe some traffic # going in... ipfw add 1000 pipe 1 all from myurl.com to any in via $oif # and out... ipfw add 1001 pipe 2 all from any to ...


1

are you allowing tcp/80 "new" connections? what port is apache listening on, and where should connections be accepted from? these rules shouldnt be causing any slowdown: 00200 allow tcp from any to any dst-port 80,443 in setup keep-state 00210 allow tcp from any to any dst-port 80,443 out setup keep-stat perhaps these ports are taxing on the ...


1

It sounds like Apache has a dependency on other services which the firewall is blocking. Without knowing what applications you're running, it's difficult to give more exact info, but you're blocking access to everything on localhost which seems wrong. Start by commenting out all of the deny lines and make sure that it works at the same speed. Then slowly ...


1

You're going to have to send ICMP through the pipe in addition to IP, since ping uses IP. Try this: sudo ipfw add pipe 1 icmp from any to 198.101.227.131 sudo ipfw add pipe 2 icmp from 198.101.227.131 to any I'm sure that there's a more succinct way to write these rules. I'll play around with it later tonight and update this.


1

Have you tried shutting down the Mountain Lion Apache instance and setting up an ssh tunnel e.g. sudo bash nohup ssh -L 80:192.168.100.2:80 -N -i ~someUser/.ssh/id_dsa someUser@192.168.100.2 & Or, alternitively using the Mountain Lion Apache instance to reverse proxy requests to the VM e.g. ProxyRequests Off ProxyPass / ...


1

Any help is much appreciated, even RTFM's if you can give a link to a resource that helps me understand it a bit better. Here it is: handbook/firewalls.html


1

There is a purpose to dropping syn packets only, but it's not (primarily) performance; it's an easy way to create a default deny rule that'll apply to incoming connections, but not return packets for an outgoing connection. A rule like this: deny tcp from any to any in setup (note that "setup" is shorthand for "tcpflags syn,!ack") will block all incoming ...


1

If you don't want to bother with natd you need kernel compiled with IPFIREWALL_FORWARD option. You can check your current kernel issuing 'sysctl kern.conftxt | grep IPFIREWALL_FORWARD'. If this option is absent you need to rebuild your kernel (or stick to pf). If you have such kernel you just need to add this rules: ipfw add allow tcp from any to ...


1

FreeBSD now comes with 3 (sic!) different firewalls, ipfw2 is just one of them, and two left are Darren Reed's ipfilter and OpenBSD's PF. Both of them has built-in NAT which supports port redirecting "from the box", see, for e. g., PF's way. So why not use them instead?


1

Disclaimer I haven't tried this but this is for workstation but I believe it should work If you are running a virtual machine on your computer, you may want to access that virtual machine from another computer. Let’s use an example: Say you have an Ubuntu virtual machine with Apache running on port 80, and you want to show other people on your network to ...


1

ipfw is the freebsd firewall package. Dummynet however is available for Linux and must be usable somehow from iptables. I haven't yet found a tutorial on how to use it with linux. I'm sure it'll exist somewhere. Looks like you have to compile it yourself. See README file that comes with the dummynet source.



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