HOWTO: iptables (part one of three)

Share your own howto's etc. Not for support questions!

HOWTO: iptables (part one of three)

Postby chrismortimore » 2007-06-18 10:23

Sorry it took so long, I've had some personal things to work through over the last few weeks. But here it is.

Introductory blurb
I've elected to do three separate guides for iptables that will cover three topics. These will be as follows:
  • Basic protection, granting access to services based on IP and/or MAC address, and Debian integration
  • Protection against port scanning, and blacklisting addresses that "misbehave"
  • Port knocking
In the true style of Debian, they'll be posted when they are ready ;)

First things first
Make sure you have the "iptables" package installed. Use your favourate package manager to do it, I won't tell you how.

Big fat notes
  • This guide only deals with filtering. It will not deal with routing or mangling. If you don't know what these are, don't worry ;) I intend this guide to be for people who just want to protect their desktop/laptop from nasty people.
  • When building a firewall, you should know exactly what you want to do with it from the outset. Firewalls take thought and planning. By all means, keep reading if you havn't a clue, and you might get some ideas, but it isn't the kind of thing where you just throw in commands and play around.
  • All of the commands need to be ran with root privilages. Amend them as you need to (be it prefixing sudo, or whatever). I just use a root console myself, but hey, I'm old fashioned.
  • If you set up your firewall badly, things will probably stop working. IP tables doesn't save the tables itself, so if you reboot, it will clear everything. This could save you. However, if you are doing this on a remote machine, that could be easier said than done ;)
  • If this guide scares you, then a GUI firewall builder might be better for you. There are many out there that are only a search away. I personally like kmyfirewall.
  • Read this guide before you do it. In fact, read any guide before you do it. It's just good sense.

IP tables basics
There are three types of packets you will normally encounter when filtering:
  • INPUT - these are inbound packets. Things like people trying to access yours. This includes you trying to access your own services. Remember that last bit, it is important.
  • FORWARD - These are routing packets. As said earlier, I won't deal with those, thus we will just block them.
  • OUTPUT - These are packets that you send.
There are three things you can do with the packets when they get processed by IP tables:
  • ACCEPT - allow the packet to do it's business.
  • REJECT - send the packet back to source with a little note saying that it isn't allowed in the system.
  • DROP - ignore the packet.
Remember these six terms. They are not exactly taxing to remember, so it isn't that much to ask ;)

Now, lets get down to how IP tables actually works. Each type of packet (INPUT, FORWARD and OUTPUT) are processed separately, but in the same manner. IP tables has a "table" of rules for each of the three packet types. For each table, there is what is termed the "Default Policy", which is either ACCEPT, REJECT or DROP. It literally starts at the top of the table, and works down until something matches the packet. If none of the rules in the table match the packet, then the default policy is applied. Make sense? Probably not, but hopefully it will shortly. On top of the three tables that IP tables gives you by default, you can make custom tables that you can use. This lets you group related rules together, and make it a bit tidier. They arn't needed, but it's nice to keep things clean.

Now, lets look at how rules are constructed. There are three parts to a rule: the table, the match criteria, and the target. The table is simply what table the rule gets inserted into (INPUT, FORWARD, OUTPUT or a custom table). The match criteria describe the situations that you want the rule to apply to (which are things like ports, addresses, and so on), but we'll cover these later on. The target is a little more interesting. The IP tables matches a rule, it sends the packet to a particular "target". These targets can be other tables, for additional processing, or it can be one of ACCEPT, REJECT and DROP. This is probably clear as mud just now, but once you see some rules, you'll be able to see how it comes together.

But what does it look like?
If you run "iptables" from a terminal, you'll get a lovely message saying "no command specified". Not what we're really after if we want to see the current table. We can do this using the "-L" option (L for list). This is what a blank table looks like:
Code: Select all
marbles:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
Here you can see the three basic tables (INPUT, FORWARD, and OUTPUT), and their default policies (ACCEPT for all of them). Very secure, everything gets in and out. But the default is not meant to imped your work, hence why it is that forgiving. If you put a table name after the -L option (such as INPUT), it will only print out that table. We'll use this later on.

Bringing it all together
So, we've covered how tables are processed and how rules are made in a very hand-waving "take my word for it" kind of way. Now comes the fun bit.

I work by this philosophy: nobody should be in my computer except me, and I don't want to be restricted in my surfing. This should imply to you that we want to keep as much of the incoming traffic out of the computer while letting everything leave the computer, which should start the cogs turning. Obvious candidates for the default policies are ACCEPT for OUTPUT, and either REJECT or DROP for INPUT. See where I got this from? If not, then I'd recommend a GUI firewall builder. Seriously.

Whether you use REJECT or DROP is purely a matter of preference. REJECT tells the source that a computer is there and that their packet has been blocked, but with DROP the source computer doesn't have a clue what has happened (but can probably guess). I personally favour DROP, because I like to be "invisible" ;) So DROP will be used in this guide, but you can swap it for REJECT if you wish.

So we've dealt with the INPUT and OUTPUT default policies, but what about FORWARD? As this guide ignores routing, we want the computer to follow suit, so we'll have the FORWARD policy as DROP.

To set our default policies, we use the "-P" option (P for policy) on each table, like so:
Code: Select all
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
The first line reads as "Set the default policy of INPUT to DROP". The other two are in the same light. Now, if we look at our table, you'll see it has changed from the default:
Code: Select all
Chain INPUT (policy DROP)
target     prot opt source               destination

Chain FORWARD (policy DROP)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
The first two default policies are now DROP, wooyay! The program is doing what we want it to!

Some basic input exceptions
So now we have locked down our computer. What about everything that had connections before? Things like current SSH connections (which might include the one you are currently accessing the computer with ;)) will suddenly stop. Because if this, we need to add our first rule, which is a bit complicated, but needed.

IP tables lets us check the "state" of connections, i.e. whether it is a new connection, an existing connection, related to an existing connection and so on. What we want to do is allow all existing connections, and any connections that relate to the existing connections. Confused? Good :) Basically, we don't want to disconnect anyone that is currently connected to the computer. This is the rule that we use to do this:
Code: Select all
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
This reads as "If the incoming connection is existing when we start the firewall, or related to an existing connection, then accept it". Because it is our first rule, we'll break it down into the three parts I mentioned earlier:
  • "-A INPUT" sets the table. It reads as "Append to the INPUT table"
  • "-m state --state RELATED,ESTABLISHED" is our matching criteria. It literally reads as "Use the state module, and match related or established connections"
  • "-j ACCEPT" is our target. It literally reads as "If the matching criteria fits, jump to ACCEPT". This is basically, if we match, accept the packet.
Basically all rules can be broken down like this, it is just a case of knowing what part is what. If we run this command, our table now looks like this:
Code: Select all
marbles:~# iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     0    --  anywhere             anywhere            state RELATED,ESTABLISHED

Chain FORWARD (policy DROP)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
See our little rule at the top of the INPUT table? Doesn't it just look lonely? Let's give it another friend.

The next rule I always use is to allow any local incoming packets. Ever wondered what your loopback device ("lo" in ifconfig) is for? It is used when you access a service locally, such as SSH into yourself, view your own web server, access your local IMAP server, etc. So, if we want to be able to get to our own services (which you usually want to do), we need to add a rule that "trusts" the loopback device. Here goes:
Code: Select all
iptables -A INPUT -i lo -j ACCEPT
This reads as "If the packet comes from the loopback device, accept it". I'm sure you can break it down into the three parts if you want. We also have a new option, the "-i" option. This is the network interface that the packet was received on.

Now, if we look at our table, you'll see the most useless line ever:
Code: Select all
arbles:~# iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     0    --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     0    --  anywhere             anywhere

Chain FORWARD (policy DROP)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
The second rule looks like it is accepting everything. We need to tell IP tables to print the table in a more verbose way, so we use the old favourate "-v" option.
Code: Select all
marbles:~# iptables -vL
Chain INPUT (policy DROP 91 packets, 8249 bytes)
 pkts bytes target     prot opt in     out     source               destination
   59  5901 ACCEPT     0    --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED
   11   660 ACCEPT     0    --  lo     any     anywhere             anywhere

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 131 packets, 9383 bytes)
 pkts bytes target     prot opt in     out     source               destination
There we go. In the "in" column, you can see that the loopback device is listed in the second rule, so it is doing what we want it to *phew*. Also note that the rules are listed in the table in the order that they are added using the "iptables" command. This is also the order that they are processed. In this guide, the order doesn't matter too much, but in the next two it will. But we'll save those for a later day ;)

With this table, you now have a pretty secure system. You can send out what you like, but nobody else will get in. Nice :) Read on for how to open ports.

Allowing access
There are three matching criteria that I think are useful when allowing packets in: port (which is set by the "--dport" option), source IP address (which is set by the "-s" option), and source MAC address (which is a little more complicated). You can use any combination of the three to build your firewall, and the order doesn't matter because they all need to match. For matching ports and such like, you need to also match the protocol using the "-p" option. This will be either "-p tcp" or "-p udp". Lets do some examples.

I want all computers to be able to access my webserver, which runs on TCP port 80. Hopefully now, you'd be able to give making this rule a bash yourself, because it is pretty simple. Here is the rule:
Code: Select all
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
And looking at the INPUT table, we get this:
Code: Select all
marbles:~# iptables -L INPUT
Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     0    --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     0    --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:www
As you can see, the last line says "ACCEPT any packets that are for port 80".

Now, I want only my laptop to be able to access SSH. My laptop always has IP address 192.168.0.3, and lets say it's MAC address is 00:11:22:33:44:55. An appropriate rule would be this:
Code: Select all
iptables -A INPUT -p tcp -m mac --mac-source 00:11:22:33:44:55 --dport 22 -s 192.168.0.3 -j ACCEPT
Because this line is a little different, I'll break it down. You may have noticed that little "-m" argument that we used in the state rule from earlier, and I kind of just washed over it because we were quite early on. Lets get down to the nitty of it all. IPtables supports modules (not the kernel ones, but a similar idea), which means happy programmers can write their own plugins for matching rules in their own magical (and usually stupid or specialised) way. If you open the iptables man page, you'll see a huge list of the modules available (in the "MATCH EXTENSIONS" section). It's pretty straight forward really, here is the part of the man page for MAC address matching:
Code: Select all
   mac
       --mac-source [!] address
              Match source MAC address.  It must be of the form XX:XX:XX:XX:XX:XX.  Note that this only makes sense  for
              packets coming from an Ethernet device and entering the PREROUTING, FORWARD or INPUT chains.
From this, you can see the module name is "mac" (which we pass to the "-m" argument), and it also lists all arguments the module itself accepts, and how to use them. Cunning, isn't it?

And as always, it makes our table look like this:
Code: Select all
Chain INPUT (policy DROP)
target     prot opt source              destination
ACCEPT     0    --  anywhere            anywhere            state RELATED,ESTABLISHED
ACCEPT     0    --  anywhere            anywhere
ACCEPT     tcp  --  anywhere            anywhere            tcp dpt:www
ACCEPT     tcp  --  192.168.0.3         anywhere            MAC 00:11:22:33:44:55 tcp dpt:ssh
By now, I'd hope you'd be able to figure out how this line relates to the rule, so I'll stop spoon feeding ;)

Just for completeness, if you only want to allow access by IP address, and not bother with MAC filtering, you would use:
Code: Select all
iptables -A INPUT -p tcp --dport 22 -s 192.168.0.3 -j ACCEPT
And likewise, you can filter only by MAC address, but I'll let you figure that out for yourself as well :)

What about allowing access from a particular range of IP addresses? Perfectly reasonable thing to ask, and it took me ages to figure out. Say you want to allow port 80 to addresses 192.168.0.2 through to 192.168.0.8. From what I have above, that would be 7 rules. But what if you want to do everyone from 192.168.0.2 to 192.168.0.200? "Eek" is an appropriate word here, so we use the "iprange" module like so:
Code: Select all
iptables -A INPUT -p tcp -m iprange --src-range 192.168.0.2-192.168.0.200 --dport 80 -j ACCEPT
Simple, isn't it? Say you want to do the same thing, but with multiple ports (that arn't consecutive, I'll cover consecutive in the next section), go look up the "multiport" module in the MATCH EXTENSIONS section of the manage, and it'll give you the low down, and you just use them in the same way we used iprange, mac filtering, and state matching. Easy as pie :)

Something that isn't just tcp
Bittorrent is a prime example of how what I've covered so far doesn't work, because I've only done TCP so far, and Bittorrent uses TCP and UDP. For arguments sake, by Bittorrent client is configured to use ports 10000 to 10020. Don't ask why, I can't even remember why I picked them. I digress.. Anyway, here is the line we would use for the TCP part:
Code: Select all
iptables -A INPUT -p tcp --dport 10000:10020 -j ACCEPT
Clever isn't it? And now you know how to use dport to set a range of consecutive ports as well :) But what about the UDP part I hear you cry? Now, I've never got one rule to work for both TCP and UDP packets, there might be a way of doing it, but I don't know. But I have a simple solution, so simple an idiot could (and did) think of it:
Code: Select all
iptables -A INPUT -p udp --dport 10000:10020 -j ACCEPT
Yup, duplicate the rule and use "udp" instead of "tcp". Not the best method, but it works.

But that's not all! What about flood pings?
Having covered TCP and UDP, we've missed one out, our old friend ICMP! For those of you that don't know what ICMP is used for, the best description I've ever come up with is "It's used for pings and stuff". I personally don't like pings. Once your network is working, the only thing they are useful for is flood pinging each other for fun (or for evil purposes). So lets block them completely!
Code: Select all
iptables -A INPUT -p icmp -j DROP
This blocks all pings quite nicely. But this could be a little harsh for you, because maybe you use pings every now and then to see if a computer is on (on those days when you can't be bothered going and checking). You can also use the "limit" module to limit how many are allowed. You could use these two lines instead:
Code: Select all
iptables -A INPUT -p icmp -m limit --limit 1/second --limit-burst 5 -j ACCEPT
iptables -A INPUT -p icmp -j DROP
I now refer you to the limit part of the man page for how the arguments set it all up:
Code: Select all
   limit
       This module matches at a limited rate using a token bucket filter.  A rule using this extension will match  until
       this  limit  is reached (unless the ‘!’ flag is used).  It can be used in combination with the LOG target to give
       limited logging, for example.

       --limit rate
              Maximum average matching rate: specified as a number, with an optional ‘/second’, ‘/minute’,  ‘/hour’,  or
              ‘/day’ suffix; the default is 3/hour.

       --limit-burst number
              Maximum  initial number of packets to match: this number gets recharged by one every time the limit speci-
              fied above is not reached, up to this number; the default is 5.
Now lets break it all down. The first rule says "ACCEPT the first 5 ICMP packets regardless of how often they occur, and then after that, ACCEPT only one per second". For everything that is outside of these limits, the second rule matches, which is simply our drop rule. This allows people to ping us, but not quickly enough that it disturbs our day.

You can of course mix this with anything else described above. I, for example, allow any pings (be them flood or not) from my laptop by matching IP address and MAC address, and every other computer on the network is only allowed to ping me once every second. This is just combining what we already know and getting the order right like this:
Code: Select all
iptables -A INPUT -p icmp -m mac --mac-source 00:11:22:33:44:55 -s toaster -j ACCEPT
iptables -A INPUT -p icmp -m limit --limit 1/second --limit-burst 1 -j ACCEPT
iptables -A INPUT -p icmp -j DROP


Saving and loading rules
We use the two commands "iptables-save" and "iptables-restore" to do this. They don't work quite as I ever expected, but are still very handy. If I run "iptables-save" just now using the last example (SSH from my laptop), I get this:
Code: Select all
marbles:~# iptables-save
# Generated by iptables-save v1.3.6 on Mon Jun 18 11:05:39 2007
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [15605:1128558]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 192.168.0.3 -p tcp -m mac --mac-source 00:11:22:33:44:55 -m tcp --dport 22 -j ACCEPT
COMMIT
# Completed on Mon Jun 18 11:05:39 2007
So the obvious way to save this, is using that nice ">" thingy, like so:
Code: Select all
iptables-save > mysuperrules
"iptables-restore" just reads the rules from STDIN and sets them as needed, so you can then reload them using this command:
Code: Select all
iptables-restore < mysuperrules
Thats about it really.

Debian Integration
Debian doesn't have any "proper" way of setting iptables rules, but it's quite easy to make it do it for us. First, I like to make a place to keep my rules (I have a few rules for different scenarios, such as laptop in the house, laptop roaming, that kind of thing). You're choice, I use /etc/iptables/ to save them. So lets say our rules are saved in the file /etc/iptables/myrules. Just now, my /etc/network/interfaces file looks like this:
Code: Select all
auto lo eth0
iface lo inet loopback

iface eth0 inet dhcp
Little bare, but it nicely starts eth0 on boot using DHCP. To make it load our rules, simply change it to this:
Code: Select all
auto lo eth0
iface lo inet loopback

iface eth0 inet dhcp
        pre-up /sbin/iptables-restore < /etc/iptables/myrules
This will load our rules before eth0 is started, so we are protected from the word go. Nice :)

Conclusion
Well, thats basically it for now. We have covered locking down the computer and then granting access by IP address and MAC address, TCP, UDP and ICMP filtering, filtering by consecutive and non-consecutive ports, limiting packet rates, packet states, and getting it all to work with Debian nicely. I'd say experiment and read the man page now, just so you get a feel of just how powerful this program really is. Remember, if you mess it up, iptables resets when you restart your machine, so it isn't the end of the world.

Next time: portscan protection and blacklisting :)

Cheers,

Chris
Desktop: AMD Athlon64 3800+ Venice Core, 2GB PC3200, 5x320GB WD 7200rpm Caviar RE2 (RAID5), Nvidia 6600GT 256MB
Laptop: Intel Pentium M 1.5GHz, 512MB PC2700, 60GB 5400rpm IBM TravelStar, Nvidia 5200Go 64MB
User avatar
chrismortimore
 
Posts: 862
Joined: 2007-04-24 06:34
Location: Edinburgh, UK

Postby sinical » 2007-06-18 10:35

Welcome back .. nice novel :wink:
Every cloud has a silver lining, except for the mushroom shaped ones, which have a lining of Strontium 90.
---------------------------------------------
umop apisdn
User avatar
sinical
 
Posts: 1022
Joined: 2007-03-25 11:52

Postby chrismortimore » 2007-06-18 10:38

sinical wrote:Welcome back .. nice novel :wink:
Cheers, good to be back :)
Desktop: AMD Athlon64 3800+ Venice Core, 2GB PC3200, 5x320GB WD 7200rpm Caviar RE2 (RAID5), Nvidia 6600GT 256MB
Laptop: Intel Pentium M 1.5GHz, 512MB PC2700, 60GB 5400rpm IBM TravelStar, Nvidia 5200Go 64MB
User avatar
chrismortimore
 
Posts: 862
Joined: 2007-04-24 06:34
Location: Edinburgh, UK

Postby GMouse » 2007-06-18 13:29

Wow, impressive!
For the sake of proper attribution, my avatar: http://www.deviantart.com/deviation/40999320/
User avatar
GMouse
 
Posts: 280
Joined: 2007-03-02 22:28
Location: Ohio, USA

Postby plb » 2007-06-18 13:37

Thanks for this nice little howto...keep up the good work :D
plb
 
Posts: 472
Joined: 2007-04-22 14:24
Location: NYC

Postby Pobega » 2007-06-18 14:03

Thanks for the awesome HowTo, but I'm still having trouble blocking pings on my laptop. No matter what rules I try, I'm still able to be pinged from my friends. My current ruleset is:

Code: Select all
Chain INPUT (policy DROP 2 packets, 64 bytes)
 pkts bytes target     prot opt in     out     source               destination

  178 56600 ACCEPT     0    --  any    any     anywhere             anywhere
      state RELATED,ESTABLISHED
    0     0 ACCEPT     0    --  lo     any     anywhere             anywhere

    0     0 DROP       icmp --  any    any     anywhere             anywhere

    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere
      tcp dpt:webcache
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere
      tcp dpt:15000

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination


Chain OUTPUT (policy ACCEPT 36390 packets, 3233K bytes)
 pkts bytes target     prot opt in     out     source               destination
Jabber: pobega@gmail.com
Pronunciation: Poh - Bay - Guh
User avatar
Pobega
 
Posts: 870
Joined: 2007-01-04 04:30
Location: New York

Postby chrismortimore » 2007-06-18 14:24

Pobega: is that the output from iptables after you've been pinged? Because if it is, the pings are matching on the first rule (the state one), as shown by it being the only one that has > 0 in the pkgs column. Bring down the network interface (ifconfig eth0 down), reconfigure iptables from scratch, and start your network interface again after iptables is going, and see if that solves anything. And lets cross our fingers ;)
Desktop: AMD Athlon64 3800+ Venice Core, 2GB PC3200, 5x320GB WD 7200rpm Caviar RE2 (RAID5), Nvidia 6600GT 256MB
Laptop: Intel Pentium M 1.5GHz, 512MB PC2700, 60GB 5400rpm IBM TravelStar, Nvidia 5200Go 64MB
User avatar
chrismortimore
 
Posts: 862
Joined: 2007-04-24 06:34
Location: Edinburgh, UK

Postby Pobega » 2007-06-18 14:30

I put the IMCP rule above the state rule, but it's not working still.

Code: Select all
root:~# iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination
DROP       icmp --  anywhere             anywhere
ACCEPT     0    --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     0    --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:webcache
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:15000


root:~# ping pobega.ath.cx
PING pobega.ath.cx (71.125.23.227) 56(84) bytes of data.

--- pobega.ath.cx ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1000ms


But, from my friend's Windows PC:

C:\Documents and Settings\Jorge Fuentes>ping pobega.ath.cx
Pinging pobega.ath.cx [71.125.23.227] with 32 bytes of data:

Reply from 71.125.23.227: bytes=32 time=14ms TTL=59
Reply from 71.125.23.227: bytes=32 time=14ms TTL=59
Reply from 71.125.23.227: bytes=32 time=12ms TTL=59
Reply from 71.125.23.227: bytes=32 time=122ms TTL=59

Ping statistics for 71.125.23.227:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:
Minimum = 12ms, Maximum = 122ms, Average = 40ms
Jabber: pobega@gmail.com
Pronunciation: Poh - Bay - Guh
User avatar
Pobega
 
Posts: 870
Joined: 2007-01-04 04:30
Location: New York

Postby hash » 2007-06-18 17:03

thx chrismortimore.
neat intro :)
Will try it sometime an thank you again.
Disclaimer: Any errors/misstakes in spilling, glammer, tact, or fact are transmission errors
User avatar
hash
 
Posts: 160
Joined: 2007-04-14 05:59
Location: Vancouver, BC, Canada

Postby chrismortimore » 2007-06-19 10:12

Pobega wrote:I put the IMCP rule above the state rule, but it's not working still.
Interesting... And unexpected... Leave this with me, I'll play around with my setup and see if I can find you a solution. But I'm going to shower first ;)
Desktop: AMD Athlon64 3800+ Venice Core, 2GB PC3200, 5x320GB WD 7200rpm Caviar RE2 (RAID5), Nvidia 6600GT 256MB
Laptop: Intel Pentium M 1.5GHz, 512MB PC2700, 60GB 5400rpm IBM TravelStar, Nvidia 5200Go 64MB
User avatar
chrismortimore
 
Posts: 862
Joined: 2007-04-24 06:34
Location: Edinburgh, UK

Postby plb » 2007-06-19 12:45

This should drop all pings...
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all


although I don't know why that iptables rule doesn't work...
plb
 
Posts: 472
Joined: 2007-04-22 14:24
Location: NYC

tcp/ip tables

Postby llivv » 2007-06-20 00:24

what can I say?
    netfilter
    . basic policy: Step 1 = meat
    .. exceptions: Step 2 = potatoes
    ... integration: Step 3 = gravy

You deserve free ale :wink:
User avatar
llivv
 
Posts: 5488
Joined: 2007-02-14 18:10
Location: cold storage

Postby GMouse » 2007-06-26 21:48

Not to be needy or anything, but... ;) could you write up the basic rules that would be required for some NAT on a system with two interfaces?
For the sake of proper attribution, my avatar: http://www.deviantart.com/deviation/40999320/
User avatar
GMouse
 
Posts: 280
Joined: 2007-03-02 22:28
Location: Ohio, USA

Postby chrismortimore » 2007-06-26 21:55

GMouse wrote:Not to be needy or anything, but... ;) could you write up the basic rules that would be required for some NAT on a system with two interfaces?
I would if I'd ever done that kind of thing :P If you can wait until August, my girlfriend is moving to Spain for a year of studying abroad, so I'll have nothing to do. I'm quite happy to then play around in VMware and see if I can cobble something together for you if you want. But it might take a while, because I will be moving to a new flat in August, have a lot of hospital appointments, and be preparing for my next year of uni. So yeah, patience is a virtue ;)
Desktop: AMD Athlon64 3800+ Venice Core, 2GB PC3200, 5x320GB WD 7200rpm Caviar RE2 (RAID5), Nvidia 6600GT 256MB
Laptop: Intel Pentium M 1.5GHz, 512MB PC2700, 60GB 5400rpm IBM TravelStar, Nvidia 5200Go 64MB
User avatar
chrismortimore
 
Posts: 862
Joined: 2007-04-24 06:34
Location: Edinburgh, UK

Postby GMouse » 2007-06-26 22:18

If I must. :wink: I should have a nice break in late August, when my summer classes end, so that'd actually work out quite nicely. You've been a great help so far. I'll be taking my finance courses between now and then, so if you want some info, etc. from there, feel free to ask.
For the sake of proper attribution, my avatar: http://www.deviantart.com/deviation/40999320/
User avatar
GMouse
 
Posts: 280
Joined: 2007-03-02 22:28
Location: Ohio, USA

Next

Return to Docs, Howtos, Tips & Tricks

Who is online

Users browsing this forum: No registered users and 2 guests

fashionable