LinuxQuestions.org
LinuxAnswers - the LQ Linux tutorial section.
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 04-21-2010, 09:04 AM   #1
mrmnemo
Member
 
Registered: Aug 2009
Distribution: linux
Posts: 527

Rep: Reputation: 51
Post FIREWALL: look ok so far?


Just wanted input for this script i have cobbeled together. Its not done yet. I am trying to think of ways to close up my outgoing while maintaining full functionality of my laptop ( irc, web stuff, a torrent or two, etc.) . Anyways, I have done some myself; as well as, pulling bits and pieces from other stuff out on the web.
I am starting to wonder why i have to write a specific rule to check for spoofed packets if my default input is set top drop. wouldnt it be caught?

Code:
#!/bin/bash
### Laptop + Desktop: No Forwarding firewall ip4 / ip6
### Distro > Debian / Ubuntu. 
### oliverteasley@gmail.com 

### Action Order: 
### 1.LOAD all modules to be used ( a just in case measure ). See http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch14_:_Linux_Firewalls_Using_iptables#Loading_Kernel_Modules_Needed_By_iptables
### 2.FLUSH all old tables/chains
### 3.CREATE needed new chains
### 4.CREATE needed scripts for loading wall at boot with pre-up config 
### 5.EDIT/ADD needed sysctl.conf settings as per references at http://www.cyberciti.biz/faq/linux-kernel-etcsysctl-conf-security-hardening/
### 6.Set up denyhosts.conf

#-------------------------------------------------------------------------------#
#                              PRE RUN WARNING                                  #
#-------------------------------------------------------------------------------#
echo -e "\033[1;32mWARNING WARNING WARNING WARNING \033[1;37m"
echo -e "\033[1;32mIF THIS IS NOT THE FIRST TIME   \033[1;37m"
echo -e "\033[1;32mYOU WILL NEED TO COMMENT OUT (#)\033[1;37m"
echo -e "\033[1;32mALL LINES STARTING WITH 'mkdir' \033[1;37m"
echo -e "\033[1;32mOR YOUR TRUSTED / BANNED / PORT \033[1;37m"
echo -e "\033[1;32m>>>>>>WILL BE OVER WRITTEN<<<<<<\033[1;37m"     
echo 
echo 'If your sure you are running this for the first time'
echo 'or you have already backed up your ip list located in'
echo '/usr/FIREWALL/(assorted list) then you can continue'
read -p "Press any key to continue"

#-------------------------------------------------------------------------------#
#                               Command Paths                                   #
#-------------------------------------------------------------------------------#

IPT="/sbin/iptables"
IPTRST="/sbin/iptables-restore"
IPTSV="/sbin/iptables-save"
MODPRB="/sbin/modprobe"
IPT6="/sbin/ip6tables" 
SYCTL="/sbin/sysctl"
ARP="/usr/sbin/arp" ###hold over for a desktop. hard to use on a rover###

#-------------------------------------------------------------------------------#
#                                RATE LIMITS                                    #
#-------------------------------------------------------------------------------#

LOGLIMIT="-m limit --limit 5/min -j LOG"
LOGLIMITSMURF="-m limit --limit 5/min -j LOG"
SSHCONLMIT="-m state --state NEW -m recent \ --update --seconds 600 --hitcount 2"

#-------------------------------------------------------------------------------#
#                     USER EDITABLE LIST LOCATIONS / PARSERS                    #
#-------------------------------------------------------------------------------#

###I put this here just do it. I do not suggest getting a list of ip from the
###internet as they change on a regular basis. anyways, here ya go.

#>ALLOWED
WHITELIST="/usr/FIREWALL/trustedip.lst"
mkdir /usr/FIREWALL/trustedip.lst -p

#>BLOCKED
BLACKLIST="/usr/FIREWALL/banip.lst"
mkdir /usr/FIREWALL/banip.lst -p

#>PORTS OPEN TO OUTSIDE
OPENPORT="/usr/FIREWALL/openport.lst"
mkdir /usr/FIREWALL/openport.lst

#>INTERFACE TO PROTECT (try ifconfig to see what ya got!)
echo "$IFACE interfaces will be covered by the iptables portion of this script"
IFACE="all"

#-------------------------------------------------------------------------------#
#                     USER EDITABLE LIST LOCATIONS / PARSERS                    #
#-------------------------------------------------------------------------------#

### Change some kernel parms to try to close things up
echo "Creating backup of current sysctl.conf in /home/$USER"
cp /etc/sysctl.conf /home/$USER
echo 'Done..'
echo
echo 'Setting root only access to sysctl.conf'
chown root:root /etc/sysctl.conf
chmod 0600 /etc/sysctl.conf
echo 'Done..'
echo
echo 'turning off send / recieve ICMP Redirects'
$SYCTL -w net.ipv4.conf.all.accept_redirects = 0
$SYCTL -w net.ipv4.conf.all.send_redirects = 0
$SYCTL -w net.ipv6.conf.all.accept_redirects = 0
$SYCTL -w net.ipv6.conf.all.send_redirects = 0
echo 'Done..'
echo 
echo 'Turning on SYN protection'
$SYCTL -w net.ipv4.tcp_syncookies = 1 
$SYCTL -w net.ipv6.tcp_syncookies = 1 
echo 'Done..'
echo
echo 'Turning on source address verification to mitigate spoofing'
$SYCTL -w net.ipv4.conf.all.rp_filter = 1 
$SYCTL -w net.ipv6.conf.all.rp_filter = 1
echo 'Done..'
echo 
echo 'Turning off ICMP response'
$SYCTL -w net.ipv4.icmp_echo_ignore_broadcasts = 1 
$SYCTL -w net.ipv6.icmp_echo_ignore_broadcasts = 1  
echo 'Done..'
echo
#-------------------------------------------------------------------------------#
#                               IPTABLES CONFIG                                 #
#-------------------------------------------------------------------------------#
echo 'Starting iptables config'
#-------------------------------------------------------------------------------#
#                               SHUT DOWN IPV6                                  #
#-------------------------------------------------------------------------------#
echo 'Block all IPv6 traffic'
# If the ip6tables command is available, try to block all IPv6 traffic.
if test -x $IPT6; then
# Set the default policies
# drop everything
echo 'Setting default of DROP for all ipv6 packets'
$IPT6 -P INPUT DROP 2>/dev/null
$IPT6 -P FORWARD DROP 2>/dev/null
$IPT6 -P OUTPUT DROP 2>/dev/null
echo 'Done..'
echo
# The mangle table can pass everything
echo 'Clearing IPV6 mangle to pass all to the pits of null'
$IPT6 -t mangle -P PREROUTING ACCEPT 2>/dev/null
$IPT6 -t mangle -P INPUT ACCEPT 2>/dev/null
$IPT6 -t mangle -P FORWARD ACCEPT 2>/dev/null
$IPT6 -t mangle -P OUTPUT ACCEPT 2>/dev/null
$IPT6 -t mangle -P POSTROUTING ACCEPT 2>/dev/null
echo 'Done..'
echo
# Delete all rules.
echo 'Flush then delete all IPV6 rulesets'
$IPT6 -F 2>/dev/null
$IPT6 -t mangle -F 2>/dev/null
echo 'Done..'
echo
# Delete all chains.
echo 'Removing all IPV6 tables'
$IPT6 -X 2>/dev/null
$IPT6 -t mangle -X 2>/dev/null
echo 'Done..'
echo
# Zero all packets and counters.
echo 'Setting all counters to zero for IPV6'
$IPT6 -Z 2>/dev/null
$IPT6 -t mangle -Z 2>/dev/null
echo 'Done..'
fi

#-------------------------------------------------------------------------------#
#                            IPTABLES ipv4 CONFIG                               #
#-------------------------------------------------------------------------------#

### Default catchall for tables
echo 'Setting default policy of DROP for INPUT and FORWARD with ALL OUTPUT allowed'
$IPT -P INPUT DROP
$IPT -P FORWARD DROP
$IPT -P OUTPUT ACCEPT
echo 'DONE..'
echo
# Set the nat/mangle tables-chains to ACCEPT
echo 'Setting nat/mangle tables to DROP'
echo 'REASON: Will be a sigle homed system right?'
echo 'The rules can be changed to suit your needs'
$IPT -t nat -P PREROUTING DROP
$IPT -t nat -P OUTPUT DROP
$IPT -t nat -P POSTROUTING DROP

$IPT -t mangle -P PREROUTING DROP
$IPT -t mangle -P INPUT DROP
$IPT -t mangle -P FORWARD DROP
$IPT -t mangle -P OUTPUT DROP
$IPT -t mangle -P POSTROUTING DROP
echo 'DONE..'
echo
### FLUSH tables
echo 'FLUSHING rule sets on all tables'
$IPT -F INPUT
$IPT -F FORWARD
$IPT -F OUTPUT
$IPT -F -t mangle
$IPT -F -t nat
$IPT -X
echo 'DONE..'
echo
### Create new user defined tables
echo 'Creating fwalert / catchall / badflag / sshdrop'
$IPT -N fwalert
$IPT -N catchall
$IPT -N badflag
$IPT -N sshdrop
$IPT -N banned
$IPT -N trusted
echo 'DONE..'
echo
#-------------------------------------------------------------------------------#
#                            IPTABLES ipv4 CONFIG                               #
#                            User defined ruleset                               #
#                              ALLOWED SERVICES                                 #
#-------------------------------------------------------------------------------#
echo ' Building rule sets..'
###localhost
echo 'ALLOWING localhost to talk to itself'
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT
echo 'DONE..'
echo
echo 'DONE..'
echo
#-------------------------------------------------------------------------------#
#                            IPTABLES ipv4 CONFIG                               #
#                            Services being probed                              #
#-------------------------------------------------------------------------------#

#TODO: ADD X11, APACHE, OTHER COMMON ATTACK VECTORS

#>SPOOFED PACKETS
echo 'Setting rule to catch some spoofed packets which sends them to our'
echo 'fwalert table for furter processing'
$IPT -A INPUT -p tcp --tcp-flags SYN,ACK SYN,ACK -m conntrack --ctstate NEW -j fwalert




#-------------------------------------------------------------------------------#
#                            IPTABLES ipv4 CONFIG                               #
#                                alert tables                                   #
#-------------------------------------------------------------------------------#

###The following tables and rules take packets forwarded from the above security
###flagged packets.

###
###fwalert table
###

$IPT -A fwalert -p tcp --tcp-flags SYN,ACK SYN,ACK -m conntrack --ctstate NEW $RLIMIT -j LOG $LOGLIMIT --log-tcp-options --log-level 4 --log-prefix "Spoofing:> "

$IPT -A fwalert -j DROP

###
###sshdrop table
###

#TODO:Add rule to pass to user space for further processing

$IPT -A sshdrop -i $IFACE -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name ssh_attempt --rsource -j LOG --log-level 4 -m limit --limit 2/second --limit-burst 5 --log-prefix "SSH connection attempt: DROPED "

$IPT -A sshdrop  -i $IFACE -p tcp --dport 22 -m state --state NEW -m recent \
  --update --seconds 600 --hitcount 2 -j DROP

###catchall table

###banned table
#TODO: Add rule to pass to user space for further processing
$IPT -A banned $LOGLIMIT --log-prefix "BANNED=IP" #>LOGGIN PORTION
###badflags table


###ALLOWING Related.
echo 'ALLOWING connections IF RELATED or already ESTABLISHED'
$IPT -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
$IPT -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
echo 'Done..'

###INCOMMING CONNECTIONS



###LOG ALERTS, ACTION, LOG, AND DROPS

###>SPOOFED PACKETS 

###Process our trusted and banned ip list
echo 'Processing trusted addresses'
	for x in `grep -v ^# $WHITELIST | awk ‘{print $1}’`; do
	echo “Permitting $x…”
	$IPT -A INPUT -t filter -s $x -j ACCEPT
	done
echo 'Done..'
echo
echo 'Processing banned addresses'
	for x in `grep -v ^# $BLACKLIST | awk ‘{print $1}’`; do
	echo “Blocking $x…”
	#$IPTABLES -A INPUT -t filter -s $x -j LOG
	$IPTABLES -A INPUT -t filter -s $x -j DROP
	done
echo 'Done..'
echo
echo 'Processing ports for world Iface'
	for port in `grep -v ^# $PORTSLIST | awk ‘{print $1}’`; do
	echo “Accepting port $port…”
	$IPTABLES -A INPUT -t filter -p tcp –dport $port -j ACCEPT
	done
echo 'Done..'
 
Old 04-21-2010, 02:31 PM   #2
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,458
Blog Entries: 54

Rep: Reputation: 2897Reputation: 2897Reputation: 2897Reputation: 2897Reputation: 2897Reputation: 2897Reputation: 2897Reputation: 2897Reputation: 2897Reputation: 2897Reputation: 2897
Could you attach the output from running 'cat /proc/net/ip_tables_names | xargs -iT iptables -vxnL --line-numbers -t 'T';'?
 
Old 04-21-2010, 10:10 PM   #3
mrmnemo
Member
 
Registered: Aug 2009
Distribution: linux
Posts: 527

Original Poster
Rep: Reputation: 51
i am not using the above, so the output would be pointless. HOWEVER....thanks for asking me to do that as i didnt change something that was running from a script i had used after install. real question is...how the hell did you know??? damn.

anyways, here is the info you asked for:
Code:
Chain PREROUTING (policy ACCEPT 2571 packets, 544212 bytes)
num      pkts      bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 1759 packets, 110211 bytes)
num      pkts      bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 1759 packets, 110211 bytes)
num      pkts      bytes target     prot opt in     out     source               destination         
Chain PREROUTING (policy DROP 2 packets, 322 bytes)
num      pkts      bytes target     prot opt in     out     source               destination         

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

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

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

Chain POSTROUTING (policy DROP 0 packets, 0 bytes)
num      pkts      bytes target     prot opt in     out     source               destination         
Chain INPUT (policy DROP 0 packets, 0 bytes)
num      pkts      bytes target     prot opt in     out     source               destination         
1           0        0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
2           0        0 fwalert    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x12/0x12 ctstate NEW 
3           0        0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           ctstate RELATED,ESTABLISHED 

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

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num      pkts      bytes target     prot opt in     out     source               destination         
1           0        0 ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0           
2           0        0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           
3           0        0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           ctstate RELATED,ESTABLISHED 

Chain badflag (0 references)
num      pkts      bytes target     prot opt in     out     source               destination         

Chain badflags (0 references)
num      pkts      bytes target     prot opt in     out     source               destination         
1           0        0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 15/min burst 5 LOG flags 0 level 4 prefix `Badflags:' 
2           0        0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain banned (0 references)
num      pkts      bytes target     prot opt in     out     source               destination         
1           0        0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 5/min burst 5 LOG flags 0 level 4 prefix `BANNED=IP' 

Chain catchall (0 references)
num      pkts      bytes target     prot opt in     out     source               destination         

Chain dropwall (0 references)
num      pkts      bytes target     prot opt in     out     source               destination         
1           0        0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 15/min burst 5 LOG flags 0 level 4 prefix `Dropwall:' 
2           0        0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain firewall (0 references)
num      pkts      bytes target     prot opt in     out     source               destination         
1           0        0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 15/min burst 5 LOG flags 0 level 4 prefix `Firewall:' 
2           0        0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain fwalert (1 references)
num      pkts      bytes target     prot opt in     out     source               destination         
1           0        0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain silent (0 references)
num      pkts      bytes target     prot opt in     out     source               destination         
1           0        0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain sshdrop (0 references)
num      pkts      bytes target     prot opt in     out     source               destination         
1           0        0 DROP       tcp  --  all    *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 state NEW recent: UPDATE seconds: 600 hit_count: 2 name: DEFAULT side: source 

Chain trusted (0 references)
num      pkts      bytes target     prot opt in     out     source               destination

Last edited by mrmnemo; 04-21-2010 at 11:06 PM. Reason: adding requested info
 
Old 04-22-2010, 12:18 AM   #4
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
Quote:
Originally Posted by mrmnemo View Post
I am starting to wonder why i have to write a specific rule to check for spoofed packets if my default input is set top drop. wouldnt it be caught?

[...]

Code:
#>SPOOFED PACKETS
echo 'Setting rule to catch some spoofed packets which sends them to our'
echo 'fwalert [chain] for furter processing'
$IPT -A INPUT -p tcp --tcp-flags SYN,ACK SYN,ACK -m conntrack --ctstate NEW -j fwalert
Is this the rule you're referring to? If so, could you explain why you consider it to be an anti-spoofing rule? AFAICT, it simply matches packets in state NEW which have both the SYN and ACK flags set – such packets may indeed be unwelcome (since a SYN-ACK is a reply to a SYN and should therefore be in state ESTABLISHED), but TCP flag combinations don't determine whether a packet is spoofed or not.

Last edited by win32sux; 04-22-2010 at 12:22 AM.
 
Old 04-22-2010, 12:24 AM   #5
mrmnemo
Member
 
Registered: Aug 2009
Distribution: linux
Posts: 527

Original Poster
Rep: Reputation: 51
well, all i am doing is putting together tidbits from assorted scripts. In doing so I am learning how to build a firewall ( well sorta). I am saying "spoofed" because when i google the above snipit is what should stop a spoof (tcp based) anyways. If you have any sugestions on search strings that i should check i welcome them. as i said, i am just trying to learn. My issue is that i have to learn SO MUCH. So, yeah, I was parroting what i had found via google.
 
Old 04-22-2010, 12:33 AM   #6
mrmnemo
Member
 
Registered: Aug 2009
Distribution: linux
Posts: 527

Original Poster
Rep: Reputation: 51
Quote:
Originally Posted by win32sux View Post
(since a SYN-ACK is a reply to a SYN and should therefore be in state ESTABLISHED)
Thats what my reading is showing. So my understanding is: if my default INPUT is DROP then all I really need is ESTABLISHED, RELATED with conntrack right? I mean, everything else is just to get info into the logs to see whats going on correct?

I have seen some very complex firewall scripts which block for everything under the sun. However, with a default DROP on INPUT why bother dropping certain packets that dont match ESTABLISHED, RELATED? I can understand LOG jumps, just cant wrap my head around the double drops. Anyways, I have put together the iptables portion of the script based on what i have seen out on the web. However, as stated above, the logic seems weird.

Quote:
Originally Posted by win32sux View Post
but TCP flag combinations don't determine whether a packet is spoofed or not.
I would welcome a sugested read on this.
 
Old 04-22-2010, 12:36 AM   #7
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
Quote:
Originally Posted by mrmnemo View Post
well, all i am doing is putting together tidbits from assorted scripts. In doing so I am learning how to build a firewall ( well sorta). I am saying "spoofed" because when i google the above snipit is what should stop a spoof (tcp based) anyways. If you have any sugestions on search strings that i should check i welcome them. as i said, i am just trying to learn. My issue is that i have to learn SO MUCH. So, yeah, I was parroting what i had found via google.
Well, I'd recommend you modify your approach and dive into this tutorial instead.

Honestly, taking a few days to learn the fundamentals will be much more valuable to you than just mindlessly copy/pasting iptables commands from all over the Internet.
 
Old 04-22-2010, 12:45 AM   #8
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
Quote:
Originally Posted by mrmnemo View Post
Thats what my reading is showing. So my understanding is: if my default INPUT is DROP then all I really need is ESTABLISHED, RELATED with conntrack right? I mean, everything else is just to get info into the logs to see whats going on correct?
That's certainly the case for a lot of scenarios. For example, the INPUT chain on the computer I'm using right now has a policy of DROP and only two rules:
Code:
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
Quote:
I have seen some very complex firewall scripts which block for everything under the sun. However, with a default DROP on INPUT why bother dropping certain packets that dont match ESTABLISHED, RELATED? I can understand LOG jumps, just cant wrap my head around the double drops. Anyways, I have put together the iptables portion of the script based on what i have seen out on the web. However, as stated above, the logic seems weird.
This sort of stuff will become clear to you after you've followed a good introduction to iptables. Basically, even though packets are in state ESTABLISHED or RELATED there are cases when you'd want to filter them. As an example, certain TCP flag combinations might be deemed unacceptable by the network administrator, and he/she would therefore have rules in place to filter such packets. As for jumps, I'd suggest you keep things as simple as possible. User-built chains are intended to make things simpler, not more confusing, so don't use them unless they serve that purpose.

Quote:
I would welcome a sugested read on this.
Well, spoofing is about making the source address on the packet be fake. That should be enough to understand why the TCP flags are irrelevant. There's a Wikipedia article you could read, though.

FWIW, your script is enabling anti-spoofing measures in this section:
Quote:
echo 'Turning on SYN protection'
$SYCTL -w net.ipv4.tcp_syncookies = 1
$SYCTL -w net.ipv6.tcp_syncookies = 1
echo 'Done..'
echo
echo 'Turning on source address verification to mitigate spoofing'
$SYCTL -w net.ipv4.conf.all.rp_filter = 1
$SYCTL -w net.ipv6.conf.all.rp_filter = 1

Last edited by win32sux; 04-22-2010 at 01:36 AM.
 
Old 04-22-2010, 12:51 AM   #9
mrmnemo
Member
 
Registered: Aug 2009
Distribution: linux
Posts: 527

Original Poster
Rep: Reputation: 51
I understand your point. What I am saying is that each "attack" has a foot print. At the same time I wouldnt call it mindless copying / pasting. I have been searching info up on each command prior to adding it. For example: why do i have to run anything more than 2 rules on my INPUT chain? ESTABLISHED, RELATED or DROP.. But i see like a million rules for what appear to be very similar flags in the tcp header. could you explain that part? I thought conntracking was meant to take care of? I can see running packets through que and set...those make sense for nat and mangle . arrrgh....
 
Old 04-22-2010, 01:05 AM   #10
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
I had misread your question in my previous reply. I thought you were asking about sending certain packets in state ESTABLISHED or RELATED to DROP. Evidently, you were asking about the inverse.
Quote:
Originally Posted by mrmnemo View Post
with a default DROP on INPUT why bother dropping certain packets that dont match ESTABLISHED, RELATED?
You mean before they run into the chain's policy? One reason could be to reduce log file clutter (assuming that the packets would have otherwise been sent to LOG by a rule).

Last edited by win32sux; 04-22-2010 at 01:08 AM.
 
Old 04-22-2010, 01:26 AM   #11
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
Quote:
Originally Posted by mrmnemo View Post
I understand your point. What I am saying is that each "attack" has a foot print.
I agree with you. I would, however, highly recommend that if you want to filter with iptables based on attack footprints you use a solution such as psad (which uses Snort signatures) instead. Okay, perhaps not "instead", but most certainly "in addition to", as there's only so much you can do from an iptables script on its own. You might be better off looking into this later, though, when you're more familiar with iptables.

Quote:
At the same time I wouldnt call it mindless copying / pasting. I have been searching info up on each command prior to adding it. For example: why do i have to run anything more than 2 rules on my INPUT chain? ESTABLISHED, RELATED or DROP.. But i see like a million rules for what appear to be very similar flags in the tcp header. could you explain that part?
You don't "have" to do any of this, it's all completely optional.

But yeah, what you're referring to sounds like so-called "bad packet chains". With those, you're basically saying "I don't want packets that look like this to come into my network". Depending on how the bad packet chain is implemented, it could apply to packets regardless of what their state is. In other words, state doesn't need to be the ultimate determinant for whether a packet is granted or denied entry/exit.

Quote:
I thought conntracking was meant to take care of?
Well, it doesn't. A lot of what goes into determining what makes a packet "bad" will be heavily dependant on the specific environment in which the firewall is deployed. In fact, a lot of it will be subjective too, so it makes sense for connection tracking to stay out the administrator's way, IMHO.

Last edited by win32sux; 04-22-2010 at 01:47 AM.
 
Old 04-22-2010, 04:16 AM   #12
salasi
Senior Member
 
Registered: Jul 2007
Location: Directly above centre of the earth, UK
Distribution: SuSE, plus some hopping
Posts: 3,910

Rep: Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776
Quote:
Originally Posted by mrmnemo
well, all i am doing is putting together tidbits from assorted scripts. In doing so I am learning how to build a firewall ( well sorta). I am saying "spoofed" because when i google the above snipit is what should stop a spoof (tcp based) anyways. If you have any sugestions on search strings that i should check i welcome them. as i said, i am just trying to learn. My issue is that i have to learn SO MUCH. So, yeah, I was parroting what i had found via google.
Quote:
Originally Posted by win32sux View Post
Well, I'd recommend you modify your approach and dive into this tutorial instead.

Honestly, taking a few days to learn the fundamentals will be much more valuable to you than just mindlessly copy/pasting iptables commands from all over the Internet.
To me, there seem to be two ways of proceeding:
  • Take existing scripts, analyse them in extreme detail, understanding them and modifying them to your needs
  • Start from a tutorial, understand at least the vital bits, build from the ground up

As far as I can tell, you seem to be doing a bit of both, but not actually doing either thoroughly. The method suggested by win32sux worked for me (although I'd suggest that you download the pdf version, rather than browse to html one every time that you need it...you'll be looking at it more than once) but, if you have a different learning style, you might find that going the other way helps you to get started. But, you'll still want the froxentux manual for reference, when it comes to the syntax of commands.

You have already found the linuxhomenetworking site, and that, and the companion book, The Linux Quick Fix Notebook (Harrison), has one of my favourite examples. You could also look at yolinux as an alternative and less complex treatment (actually, the only thing that I think is wrong with the Harrison treatment for a neophyte to firewalling is that he tries to cope with too many options in his script, which makes the script, but not necessarily the ruleset, a bit intimidating at first).

The important thing is to thoroughly understand what the original author is doing and not just half understand and dive in making 'random' changes.

Of course, you can argue that the difference between the two approaches is a bit like 'top down' and 'bottom up' software design and the advantages and disadvantages of the two approaches; in an ideal world, you'd master both, and be able to switch between the two ways of thinking, but you have to start from somewhere.
 
Old 04-22-2010, 09:58 AM   #13
mrmnemo
Member
 
Registered: Aug 2009
Distribution: linux
Posts: 527

Original Poster
Rep: Reputation: 51
At this point I guess it back to the tutorial stuff. I cant thanks you both enough.

@salasi> Yeah, I seem to pick things up better when doing hands on WITH a book. So, practical application along side a book tends to stick with me better.

@win32suks> Your correct. Thanks
 
  


Reply

Tags
iptables


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
old CISCO PIX 515 firewall to Linux firewall Winanjaya Linux - Security 8 03-22-2010 11:56 AM
pptp gets modem hung up outside firewall, but not inside firewall cmnorton Linux - Networking 4 11-27-2008 12:04 AM
router billion 5102 has firewall and software firewall tests aus9 Linux - Security 6 12-31-2006 10:09 PM
Firewall Builder sample firewall policy file ? (.xml) nuwanguy Linux - Networking 0 09-13-2003 12:32 PM


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

Main Menu
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
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration