Tag Info

Hot answers tagged

17

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 ...


7

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 ...


5

I was able to get this working using the ifconfig and pfctl commands on Mac 10.10.2. With the following approach I'm successfully mapping 127.0.0.1:3000 to mydomain.com locally on my machine. In your command line enter the following two commands to forward connections to 127.0.0.1:3000 to 10.0.0.1: sudo ifconfig lo0 10.0.0.1 alias echo "rdr pass on lo0 ...


4

If I remember correctly: PF has a special interface for monitoring purposes (pflog). You might wanna consult the manpage for it.


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 ...


3

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://xeiam.com/port-forwarding-80-to-8080-using-ipfw-on-mac-os-x/ add 100 fwd 127.0.0.1,8080 tcp from any to any 80 in


3

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 ...


2

For IIS at least one option is Dynamic IP Restrictions which is a supported addon for IIS 7 from Microsoft. It's features include: Dynamically blocking of requests from IP address based on either of the following criteria: The number of concurrent requests. The number of requests over a period of time. It can be installed with the Web ...


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

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 ...


2

I was looking to do the same on OSX (more specifically, allow phones/tablets/devices/people to access my VM for testing purposes) and the following worked perfectly: My setup: Host OSX IP: 192.168.1.72 VM IP: 172.16.67.188 Method: 1) Select “NAT” in “Network Adapter” settings on VMWare Fusion 2) cd to the vmnet8 directory cd ...


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

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

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

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).


1

I'm playing around with this myself. Try also setting your src-port to be the same. This works fine for me: # sudo ipfw pipe 1 config delay 500ms # sudo ipfw add 1 pipe 1 src-port 9160 # sudo ipfw add 2 pipe 1 dst-port 9160 Viewing the ipfw settings helps debugging any problems too: # sudo ipfw show 00001 58 69110 pipe 1 ip from any 9160 to any ...


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?



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