LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 08-12-2004, 06:19 PM   #31
Obie
Member
 
Registered: Apr 2004
Distribution: Red Hat
Posts: 290

Original Poster
Rep: Reputation: 30

quote:
--------------------------------------------------------------------------------
Originally posted by Obie Thank you all for your help. I do have a couple more queries.

I flushed all my rules within iptables and have the following listed as local policy

Chain INPUT (policy DROP)
target prot opt source destination

Chain FORWARD (policy DROP)
target prot opt source destination

Chain OUTPUT (policy DROP)
target prot opt source destination

--------------------------------------------------------------------------------

quote:
--------------------------------------------------------------------------------

1) What does "opt" refer to?
Hmm.. No idea..
--------------------------------------------------------------------------------

Does anyone know?

quote:
--------------------------------------------------------------------------------
Allow your web traffic with --dport 80 in OUTPUT chain or --source www.etc.com in your INPUT chain.. You send to port 80, but can get the resulting reply from another port.
--------------------------------------------------------------------------------

Ok. Why do certain guides mention --dport in the INPUT chain for example when blocking Port 113.
 
Old 08-13-2004, 02:23 AM   #32
barisdemiray
Member
 
Registered: Sep 2003
Location: Ankara/Turkey
Distribution: Slackware
Posts: 155

Rep: Reputation: 30
Quote:
Originally posted by Obie
quote:
--------------------------------------------------------------------------------
Allow your web traffic with --dport 80 in OUTPUT chain or --source www.etc.com in your INPUT chain.. You send to port 80, but can get the resulting reply from another port.
--------------------------------------------------------------------------------

Ok. Why do certain guides mention --dport in the INPUT chain for example when blocking Port 113.
Because some of malicious program's port numbers are fixed. For example, a SubSeven lamer tries to connect port 1243 of infected computer. So you must block the traffic that has a destination of port 1243 and can do this by using a --destination-port 1243 in the INPUT chain. Also when you want to block SSH requests, again you must use --destination-port 22 for a working sshd on it's standart port. But there is no warranty for a port number in a web connection as i said before.
 
Old 08-13-2004, 02:28 AM   #33
Capt_Caveman
Senior Member
 
Registered: Mar 2003
Distribution: Fedora
Posts: 3,658

Rep: Reputation: 69
opt = packet "fragmentation options"

i.e. specifying to match packet fragments (-f) or not fragmented (! -f) packets
 
Old 08-13-2004, 02:42 AM   #34
Obie
Member
 
Registered: Apr 2004
Distribution: Red Hat
Posts: 290

Original Poster
Rep: Reputation: 30
Capt_Caveman,

Thank you. When would there be any reference under "opt" or should I say when would someone match packet fragments?

barisdemiray,

Thank you.
 
Old 08-13-2004, 03:31 AM   #35
barisdemiray
Member
 
Registered: Sep 2003
Location: Ankara/Turkey
Distribution: Slackware
Posts: 155

Rep: Reputation: 30
Quote:
Originally posted by Obie
When would there be any reference under "opt" or should I say when would someone match packet fragments?
For example if a TCP/IP packet is bigger than maximum packet size, it will be fragmented and only first one will contain the valid headers. So, when you want to block SSH traffic, you can LOG the first part (containing valid headers) and DROP the remaining part if there are any. An iptables rule like below will be shown in iptables -L output and DROP any fragment of TCP packet traffic:

Code:
rhinox:~# iptables -L INPUT
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
rhinox:~# iptables -A INPUT -p tcp -f -j DROP
rhinox:~# iptables -L INPUT
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
DROP       tcp  -f  anywhere             anywhere
rhinox:~#
PS: Thanks for the explanation Capt_Caveman!
 
Old 08-13-2004, 09:35 AM   #36
/bin/bash
Senior Member
 
Registered: Jul 2003
Location: Indiana
Distribution: Mandrake Slackware-current QNX4.25
Posts: 1,802

Rep: Reputation: 47
Quote:
2) Say for example I wish to allow icmp(ping) requests from my box, I would use the following command iptables -A OUTPUT -p icmp -s 192.168.0.1 -d 192.168.0.2 -j ACCEPT. This would allow me to send out icmp packets. What I am attempting to comprehend is that I also noticed I require an INPUT rule. Is this because (A) I must allow the packet to return with a reply (B) completely something else. Also would this be the case for every OUTPUT rule I create? How does it affect INPUT rules?
Iptables can track packets based on these states:
NEW, ESTABLISHED, RELATED and INVALID

So if you want to be able to ping and receive ping replys you need to allow ESTABLISHED / RELATED packets. This will cover all traffic including ftp http etc...

The rule would look something like this:
$IPTABLES -A INPUT -p ALL -d eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

For forwarding it looks like this:
$IPTABLES -A FORWARD -i $LAN_IFACE -j ACCEPT
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
 
Old 08-14-2004, 06:16 AM   #37
Obie
Member
 
Registered: Apr 2004
Distribution: Red Hat
Posts: 290

Original Poster
Rep: Reputation: 30
quote:
------------------------------------------------------------------------------
Iptables can track packets based on these states:
NEW, ESTABLISHED, RELATED and INVALID

So if you want to be able to ping and receive ping replys you need to allow ESTABLISHED / RELATED packets. This will cover all traffic including ftp http etc...

The rule would look something like this:
$IPTABLES -A INPUT -p ALL -d eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

For forwarding it looks like this:
$IPTABLES -A FORWARD -i $LAN_IFACE -j ACCEPT
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
------------------------------------------------------------------------------

/bin/bash,

Thanks. I read the man pages of -m state --state however don't quite get what the states "NEW, ESTABLISHED, RELATED and INVALID" are for. Would you mind giving examples of each and when I would use them. I appreciate your help.
 
Old 08-14-2004, 07:17 AM   #38
barisdemiray
Member
 
Registered: Sep 2003
Location: Ankara/Turkey
Distribution: Slackware
Posts: 155

Rep: Reputation: 30
Quote:
Originally posted by Obie
quote:
------------------------------------------------------------------------------
Iptables can track packets based on these states:
NEW, ESTABLISHED, RELATED and INVALID

So if you want to be able to ping and receive ping replys you need to allow ESTABLISHED / RELATED packets. This will cover all traffic including ftp http etc...

The rule would look something like this:
$IPTABLES -A INPUT -p ALL -d eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

For forwarding it looks like this:
$IPTABLES -A FORWARD -i $LAN_IFACE -j ACCEPT
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
------------------------------------------------------------------------------

/bin/bash,

Thanks. I read the man pages of -m state --state however don't quite get what the states "NEW, ESTABLISHED, RELATED and INVALID" are for. Would you mind giving examples of each and when I would use them. I appreciate your help.
NEW: Packets which are for opening a new connection. For example if you want to block ftp, ssh connections, then block the NEW packets.
ESTABLISHED: Packets which are belonging to already opened connection. For example when you connect to a host with ssh and give the command `ls' then this packets will have the status ESTABLISHED.
RELATED: Packets which are going to open a new connection but coming from an ESTABLISHED connection. For example when you're connected to a host with ftp and going to begin a file transfer; then your ftp client will open a ftp-data connection and these packets will have the status RELATED.
INVALID: As it's name said, they neither open a new connection nor belong to already opened one. The seem random and so they're INVALID.
 
Old 08-14-2004, 11:48 PM   #39
Obie
Member
 
Registered: Apr 2004
Distribution: Red Hat
Posts: 290

Original Poster
Rep: Reputation: 30
barisdemiray,

Thanks. Just a few queries in relation to your reply:

"NEW: Packets which are for opening a new connection. For example if you want to block ftp, ssh connections, then block the NEW packets."
If I wish to block FTP for example why wouldn't I just block tcp port 21 rather than apply the status NEW

"ESTABLISHED: Packets which are belonging to already opened connection. For example when you connect to a host with ssh and give the command `ls' then this packets will have the status ESTABLISHED"
This I get that if a connection is successful then it has the status ESTABLISHED however how does that relate to iptables

"RELATED: Packets which are going to open a new connection but coming from an ESTABLISHED connection. For example when you're connected to a host with ftp and going to begin a file transfer; then your ftp client will open a ftp-data connection and these packets will have the status RELATED."
This I kinda get but it confuses me due to the examples above.
 
Old 08-15-2004, 12:50 AM   #40
futhark
Member
 
Registered: Nov 2003
Location: Montréal (Can)
Distribution: FC4
Posts: 110

Rep: Reputation: 15
Quote:
Originally posted by ppuru
True, a default INPUT DROP with no additional rules INPUT rules to accept specific traffic will block all incoming traffic (including the traffic from your local interface lo).
You must have come across documentation mentioning different firewall philosophies, for instance mostly open , mostly closed. It is my understanding that mostly closed firewalls are the most secure. The idea behind this approach is to reject all traffic that is not explicitely allowed. It is expressed in iptables by setting default policies set to DROP.

Note that if you work on your firewall box remotely it is quite possible that you will lock yourself out a few time, ie you will block your own local network traffic. This will happen more specifically if you flush your rules while the default input policy is set to drop. The solution is to log locally on the firewall box and force the default policy to accept.

You'll also discover eventually that other tables than accept, output and forward exist, namely the nat and mangle tables. You should leave these tables policies to accept. Port forwarding is insanely difficult (impossible?) otherwise.

For the input, output and forward chains, I apply drop, accept and drop default policies resp. My rationale:
- Traffic originating from the internet is considered unsafe. Since it goes through the input and forward chain, the default policy for these chains shall be drop.
- The output chain is used by the firewall box itself. I do not have a need to restrict outgoing traffic (it is a home firewall in a safe environment), so I leave this chain default policy to accept. It makes the firewall a bit less complex too.

One of the best iptables docs I have found is this one. It is very thorough.
http://iptables-tutorial.frozentux.n...-tutorial.html

Just wanted to share my 2 cents! Good luck!
 
Old 08-16-2004, 05:17 AM   #41
Obie
Member
 
Registered: Apr 2004
Distribution: Red Hat
Posts: 290

Original Poster
Rep: Reputation: 30
I just noticed something. Everytime I restart the PC or start it up, the rules I assigned to the chains within iptables are lost and all policies are set to ACCEPT despite the fact that I had changed it earlier. Is there any reason why iptables would automatically flush itself on a reboot or start up? What can I do to prevent it from doing so?
 
Old 08-16-2004, 04:34 PM   #42
Obie
Member
 
Registered: Apr 2004
Distribution: Red Hat
Posts: 290

Original Poster
Rep: Reputation: 30
I did manage to isolate it to me removing shorewall from the runlevels however how do I prevent it from flushing itself on every restart or power-up?

Last edited by Obie; 08-17-2004 at 04:15 AM.
 
Old 08-16-2004, 04:50 PM   #43
Capt_Caveman
Senior Member
 
Registered: Mar 2003
Distribution: Fedora
Posts: 3,658

Rep: Reputation: 69
On redhat/fedora systems, you need to use the command:

iptables-save > /etc/sysconfig/iptables

This should make the changes to iptables persistant after reboots. As a side note, I'm not trying to tell you to RTFM, but most of this information is readily available in the netfilter website docs or in the iptables man page. Redhat also maintains fairly comprehensive docs on iptables/netfilter and it's Redhat-specific usage.
 
Old 08-17-2004, 04:17 AM   #44
Obie
Member
 
Registered: Apr 2004
Distribution: Red Hat
Posts: 290

Original Poster
Rep: Reputation: 30
Capt_Caveman,

Thank you however that's wherein the problem lies. Mandrake does not have the path /etc/sysconfig/iptables not does Mandrake document it.
 
Old 08-17-2004, 04:50 PM   #45
/bin/bash
Senior Member
 
Registered: Jul 2003
Location: Indiana
Distribution: Mandrake Slackware-current QNX4.25
Posts: 1,802

Rep: Reputation: 47
The file /etc/sysconfig/iptables is created the first time you use that command. After that there is a startup script at /etc/rc.d/init.d/iptables which looks for the file and if it finds the file it will load the rules from it. So you only need to run that command one time. The same thing happens if you run the command:
service iptables save
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
An error occured getting IPtables status from the command /etc/rc.d/init.d/iptables s CrazyMAzeY Linux - Newbie 10 08-12-2010 05:25 AM
Iptables - Couldn't load target `ACCPET':/lib/iptables/libipt_ACCPET.so: z00t Linux - Security 3 01-26-2004 02:24 AM
IPtables Log Analyzer from http://www.gege.org/iptables/ brainlego Linux - Software 0 08-11-2003 06:08 AM
iptables book wich one can you pll recomment to be an iptables expert? linuxownt Linux - General 2 06-26-2003 04:38 PM
My iptables script is /etc/sysconfig/iptables. How do i make this baby execute on boo ForumKid Linux - General 3 01-22-2002 07:36 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 07:13 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration