Tag Info

Hot answers tagged

14

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

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


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

From my understanding, it seems that you only use one local dev machine, means not connected to any network that provides a DNS. If i am right, i would suggest to setup things like described below : step 1 : Assign at least two IP address to your MAC OS (one per domain), let's say : 192.168.0.10 192.168.0.11 To setup the second IP you will have to add a ...


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://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

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

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

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

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

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

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

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

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

First, there's no need to specify tcp and udp if you're allowing all ip in the first place. Also, it's usually easier to start your rules with allow ip from me to any to allow all outbound connections. Try this ruleset and see what happens: 00100 allow ip from me to any 00200 allow ip from 123.123.123.123 to me ssh 01000 allow icmp from any to any 01001 ...


1

ipfw add 666 fwd 127.0.0.1,80 tcp from me to any 80 not uid user_proxy This should theoretically forward locally generated traffic directed at some port 80 to localhost:80, where the proxy is running under the user_proxy user. I have no idea why this doesn't work. On my system the machine just dies after I do it (OS X 10.8). Did you manage to solve your ...


1

If you have a bridged connection, you do not need to forward traffic. All you need to do is configure the virtual network adapter with a valid IP address on the same subnet as the host, or let it request one via DHCP. If you really want the host to be responsible for forwarding traffic from the guest machine and you want to configure this forwarding ...


1

At the end of this page you'll find examples for NAT with ipfw. I hope this helps. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html


1

turns out that the allow statement for mysql traffic "blocked" it, since it was prevented in reaching the divert rule that would do the actual forwarding. testing was done by adding this rule : ipfw add 1350 skipto 1700 tcp from a.b.c.e to me dst-port 3306 As a result rules 1400 and 1600 will be removed from our firewall and mysql replication will then ...


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