Identifiying and modifying packets

Identifiying and modifying packets

[aragonx]

Hello all,

I have an application that was written to work on an internal network. 
Now, there is a requirement that we provide access from the Internet.  No
big deal so far.  We setup a Suse Linux box that acts as a gateway and all
works well.

However, this application has certain group accounts that we feel are
dangerous to allow access from the Internet.  We can't get the source code
to the application but the usernames are sent in clear text from the Linux
box to the application server.

Can someone tell me what tools I could use to examine outbound packet data
for the usernames and modify it if it matches a list of accounts we want
to block?

I suggested we just drop them but this causes the application to crash.

Any suggestions would be greatly appreciated.

---
Will Y.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: Identifiying and modifying packets

[Kristian Evensen]

Hi,
> Can someone tell me what tools I could use to examine outbound packet data
> for the usernames and modify it if it matches a list of accounts we want
> to block?
>
>   
I suggest writing your own netfilter-module that does the packet 
inspection, and if a packet matches you can simply return NF_DROP to 
instruct the kernel to drop the packet. A good tutorial/book is 
available here: http://jengelh.medozas.de/

Maybe you can do something similar with libpcap, but I am not sure if 
you can drop packets.

-Kristian

Re: Identifiying and modifying packets

[aragonx]

> Hi,
>> Can someone tell me what tools I could use to examine outbound packet
>> data
>> for the usernames and modify it if it matches a list of accounts we want
>> to block?
>>
>>
> I suggest writing your own netfilter-module that does the packet
> inspection, and if a packet matches you can simply return NF_DROP to
> instruct the kernel to drop the packet. A good tutorial/book is
> available here: http://jengelh.medozas.de/
>
> Maybe you can do something similar with libpcap, but I am not sure if
> you can drop packets.

I would love to just drop the packets but this causes the client
application to crash.  So I think I need to modify ones that match to an
invalid user name.  I've seen it mentioned that libpcap can capture the
traffic, I have not seen where it can modify and then send it on.  Can it
do that?

---
Will Y.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: Identifiying and modifying packets

[Kristian Evensen]

aragonx@dcsnow.com skrev:
>> Hi,
>>     
>>> Can someone tell me what tools I could use to examine outbound packet
>>> data
>>> for the usernames and modify it if it matches a list of accounts we want
>>> to block?
>>>
>>>
>>>       
>> I suggest writing your own netfilter-module that does the packet
>> inspection, and if a packet matches you can simply return NF_DROP to
>> instruct the kernel to drop the packet. A good tutorial/book is
>> available here: http://jengelh.medozas.de/
>>
>> Maybe you can do something similar with libpcap, but I am not sure if
>> you can drop packets.
>>     
>
> I would love to just drop the packets but this causes the client
> application to crash.  So I think I need to modify ones that match to an
> invalid user name.  I've seen it mentioned that libpcap can capture the
> traffic, I have not seen where it can modify and then send it on.  Can it
> do that?
>
>   
Yes, with Netfilter your modules recieve the skb and it will not be 
passed on until the module is finished with it. You can then toy around 
with it (including the payload) as much as you want. Section 5.6 in [1] 
shows an example of modifying the payload.

I am not sure about libpcap, I haven't used it for a while, but I think 
you only receive a copy and thus cannot change what is sent over the 
network.

-Kristian

[1] - http://jengelh.medozas.de/documents/Netfilter_Modules.pdf

Verify rules

[Scott Miller]

I was wondering if I could get someone to verify my rules.  What I am trying
to do to start with, is make only certain ports available on my outgoing
mail server - essentially blocking all other ports not listed.  I have the
below on my server in an inactive state because when I activate it, it locks
it completely down.

Could someone please take a look at my rules and share with me what I did
wrong?  Here is my entire config file:


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

*mangle
:PREROUTING ACCEPT [6:948]
:INPUT ACCEPT [6:948]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [7:3269]
:POSTROUTING ACCEPT [7:3269]
COMMIT
*nat
:OUTPUT ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
*filter
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
# HTTP
-A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 80 --state NEW -j
ACCEPT
# SSH
-A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 22 --state NEW -j
ACCEPT
# DNS
-A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 53 --state NEW -j
ACCEPT
# TIME
-A INPUT -p udp -m udp -m state NEW,ESTABLISHED --dport 123 --state NEW -j
ACCEPT
# WEBMIN
-A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 10000 --state NEW -j
ACCEPT
# SMTP
-A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 25 --state NEW -j
ACCEPT
# POP3
-A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 110 --state NEW -j
ACCEPT
# IMAP
-A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 993 --state NEW -j
ACCEPT
# RSYNC-TCP
-A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 873 --state NEW -j
ACCEPT
# RSYNC-UDP
-A INPUT -p udp -m udp -m state NEW,ESTABLISHED --dport 873 --state NEW -j
ACCEPT
# DENY ALL OTHERS
-A INPUT -i eth0 -j REJECT --reject-with icmp-net-unreachable
COMMIT

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

Thanks,
Scott Miller

Re: Verify rules

[Mike Wright]

Scott Miller wrote:
> I was wondering if I could get someone to verify my rules.  What I am trying
> to do to start with, is make only certain ports available on my outgoing
> mail server - essentially blocking all other ports not listed.  I have the
> below on my server in an inactive state because when I activate it, it locks
> it completely down.
> 
> Could someone please take a look at my rules and share with me what I did
> wrong?  Here is my entire config file:
> 
> 
> -----------------------------
> 
> *mangle
> :PREROUTING ACCEPT [6:948]
> :INPUT ACCEPT [6:948]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [7:3269]
> :POSTROUTING ACCEPT [7:3269]
> COMMIT
> *nat
> :OUTPUT ACCEPT [0:0]
> :PREROUTING ACCEPT [0:0]
> :POSTROUTING ACCEPT [0:0]
> COMMIT
> *filter
> :FORWARD ACCEPT [0:0]
> :INPUT ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> # HTTP
> -A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 80 --state NEW -j
> ACCEPT
> # SSH
> -A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 22 --state NEW -j
> ACCEPT
> # DNS
> -A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 53 --state NEW -j
> ACCEPT
> # TIME
> -A INPUT -p udp -m udp -m state NEW,ESTABLISHED --dport 123 --state NEW -j
> ACCEPT
> # WEBMIN
> -A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 10000 --state NEW -j
> ACCEPT
> # SMTP
> -A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 25 --state NEW -j
> ACCEPT
> # POP3
> -A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 110 --state NEW -j
> ACCEPT
> # IMAP
> -A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 993 --state NEW -j
> ACCEPT
> # RSYNC-TCP
> -A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 873 --state NEW -j
> ACCEPT
> # RSYNC-UDP
> -A INPUT -p udp -m udp -m state NEW,ESTABLISHED --dport 873 --state NEW -j
> ACCEPT
> # DENY ALL OTHERS
> -A INPUT -i eth0 -j REJECT --reject-with icmp-net-unreachable
> COMMIT
> 
> --------------------------

Hi Scott,

No expert here but I'll give this a try.  This is very basic but 
hopefully may provide some ideas.

You say you want to run a server so that means you should lock down 
everything you specifically don't want to serve.  That's accomplished by 
setting the INPUT chain's default policy to DROP.

#> iptables -P INPUT DROP

Let the network gossip

#> iptables -A INPUT -p icmp -m icmp --icmp-type any -j ACCEPT

We have to be able to talk to ourselves...

#> iptables -A INPUT -i lo -j ACCEPT

...and carry on a conversation.

#> iptables -A INPUT -m state --state ESTABLISHED,RELATED --j ACCEPT

With regard to unwanted traffic: UDP is stateless so we'll let the 
default DROP policy discard that.  TCP is stateful so we may or may not 
want to let the default DROP policy apply.  If we decide against 
dropping unwanted TCP traffic we may want to cleanly terminate those 
connections by resetting them

#> iptables -A INPUT -p tcp -j REJECT --reject-with  tcp-reset


We're ready.  Let's open for business and allow NEW customers

(this one is shopping for SMTP)

#> iptables -A INPUT -p tcp --dport 25 --state NEW -j ACCEPT

(this one is shopping for HTTP)

#> iptables -A INPUT -p tcp --dport 80 --state NEW -j ACCEPT


Hope that is enough to get you going  :m)

Re: Verify rules

[Mart Frauenlob]

netfilter-owner@vger.kernel.org wrote:
> I was wondering if I could get someone to verify my rules.  What I am trying
> to do to start with, is make only certain ports available on my outgoing
> mail server - essentially blocking all other ports not listed.  I have the
> below on my server in an inactive state because when I activate it, it locks
> it completely down.
>
> Could someone please take a look at my rules and share with me what I did
> wrong?  Here is my entire config file:
>
>
> -----------------------------
>
> *mangle
> :PREROUTING ACCEPT [6:948]
> :INPUT ACCEPT [6:948]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [7:3269]
> :POSTROUTING ACCEPT [7:3269]
> COMMIT
> *nat
> :OUTPUT ACCEPT [0:0]
> :PREROUTING ACCEPT [0:0]
> :POSTROUTING ACCEPT [0:0]
> COMMIT
> *filter
> :FORWARD ACCEPT [0:0]
> :INPUT ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> # HTTP
> -A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 80 --state NEW -j
> ACCEPT
> # SSH
> -A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 22 --state NEW -j
> ACCEPT
> # DNS
> -A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 53 --state NEW -j
> ACCEPT
> # TIME
> -A INPUT -p udp -m udp -m state NEW,ESTABLISHED --dport 123 --state NEW -j
> ACCEPT
> # WEBMIN
> -A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 10000 --state NEW -j
> ACCEPT
> # SMTP
> -A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 25 --state NEW -j
> ACCEPT
> # POP3
> -A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 110 --state NEW -j
> ACCEPT
> # IMAP
> -A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 993 --state NEW -j
> ACCEPT
> # RSYNC-TCP
> -A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 873 --state NEW -j
> ACCEPT
> # RSYNC-UDP
> -A INPUT -p udp -m udp -m state NEW,ESTABLISHED --dport 873 --state NEW -j
> ACCEPT
> # DENY ALL OTHERS
> -A INPUT -i eth0 -j REJECT --reject-with icmp-net-unreachable
> COMMIT
>
> --------------------------
>   

The state match syntax is wrong.

correct: -m state --state NEW,ESTABLISHED

you can write all your input allow rules in one line by using multiport 
match:
-A INPUT -p tcp -m multiport --dports 22,25,110,873,993,10000 -m state 
--state NEW,ESTABLISHED -j ACCEPT
same for udp...

Also I suggest setting INPUT policy to DROP.
Personally I'm not a friend of 'reject all unmatched'.
I prefer plain DROP, as I don't really like to send a packet for each 
not accepted connection attempt.

Read the iptables tutorial at frozentux, if you want to continue writing 
your own ruleset.
Otherwise I suggest to use a firewalling program to manage iptables. 
There's lots of them out there.

greets

Mart

RE: Verify rules

[Scott Miller]

Thanks for the suggestions - I now have the following, combining two replies
I received.  I will implement this afternoon and see what happens.  I am
also using Webmin to moidify the /etc/sysconfig/iptables file.  If anyone
sees anything wrong - please let me know.  My goal is to lock down
everything except for the mentioned ports.  Thanks for your help.

*mangle
:PREROUTING ACCEPT [6:948]
:INPUT ACCEPT [6:948]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [7:3269]
:POSTROUTING ACCEPT [7:3269]
COMMIT
*nat
:OUTPUT ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
*filter
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
# MODIFIED APRIL 27 2009 11:01AM
# TALKING TO OURSLEVES IS ALLOWED
-A INPUT -p icmp -m icmp --icmp-type any -j ACCEPT
-A INPUT -i lo -j ACCEPT
# ALLOW THE FOLLOWING TCP PROTOCOLS HTTP, SSH, DNS, WEBMIN, SMTP, POP3,
IMAP, RSYNC-TCP
-A INPUT -p tcp -m multiport -m state --state NEW,ESTABLISHED -j ACCEPT
--dports 22,25,53,80,110,873,993,10000
# ALLOW THE FOLLOWING UDP PROTOCOLS TIME, RSYNC-UDP
-A INPUT -p UDP -m multiport -m state --state NEW,ESTABLISHED -j ACCEPT
--dports 123,873
# DENY ALL OTHERS ETH0
-A INPUT -i eth0 -j DROP
# DENY ALL OTHERS ETH0:1
-A INPUT -i eth0:1 -j DROP
COMMIT




Scott Miller





-----Original Message-----
From: netfilter-owner@vger.kernel.org
[mailto:netfilter-owner@vger.kernel.org] On Behalf Of Mart Frauenlob
Sent: Friday, March 27, 2009 2:05 AM
To: netfilter@vger.kernel.org
Subject: Re: Verify rules

netfilter-owner@vger.kernel.org wrote:
> I was wondering if I could get someone to verify my rules.  What I am
trying
> to do to start with, is make only certain ports available on my outgoing
> mail server - essentially blocking all other ports not listed.  I have the
> below on my server in an inactive state because when I activate it, it
locks
> it completely down.
>
> Could someone please take a look at my rules and share with me what I did
> wrong?  Here is my entire config file:
>
>
> -----------------------------
>
> *mangle
> :PREROUTING ACCEPT [6:948]
> :INPUT ACCEPT [6:948]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [7:3269]
> :POSTROUTING ACCEPT [7:3269]
> COMMIT
> *nat
> :OUTPUT ACCEPT [0:0]
> :PREROUTING ACCEPT [0:0]
> :POSTROUTING ACCEPT [0:0]
> COMMIT
> *filter
> :FORWARD ACCEPT [0:0]
> :INPUT ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> # HTTP
> -A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 80 --state NEW -j
> ACCEPT
> # SSH
> -A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 22 --state NEW -j
> ACCEPT
> # DNS
> -A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 53 --state NEW -j
> ACCEPT
> # TIME
> -A INPUT -p udp -m udp -m state NEW,ESTABLISHED --dport 123 --state NEW -j
> ACCEPT
> # WEBMIN
> -A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 10000 --state NEW
-j
> ACCEPT
> # SMTP
> -A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 25 --state NEW -j
> ACCEPT
> # POP3
> -A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 110 --state NEW -j
> ACCEPT
> # IMAP
> -A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 993 --state NEW -j
> ACCEPT
> # RSYNC-TCP
> -A INPUT -p tcp -m tcp -m state NEW,ESTABLISHED --dport 873 --state NEW -j
> ACCEPT
> # RSYNC-UDP
> -A INPUT -p udp -m udp -m state NEW,ESTABLISHED --dport 873 --state NEW -j
> ACCEPT
> # DENY ALL OTHERS
> -A INPUT -i eth0 -j REJECT --reject-with icmp-net-unreachable
> COMMIT
>
> --------------------------
>   

The state match syntax is wrong.

correct: -m state --state NEW,ESTABLISHED

you can write all your input allow rules in one line by using multiport 
match:
-A INPUT -p tcp -m multiport --dports 22,25,110,873,993,10000 -m state 
--state NEW,ESTABLISHED -j ACCEPT
same for udp...

Also I suggest setting INPUT policy to DROP.
Personally I'm not a friend of 'reject all unmatched'.
I prefer plain DROP, as I don't really like to send a packet for each 
not accepted connection attempt.

Read the iptables tutorial at frozentux, if you want to continue writing 
your own ruleset.
Otherwise I suggest to use a firewalling program to manage iptables. 
There's lots of them out there.

greets

Mart
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.0.238 / Virus Database: 270.11.28/2022 - Release Date: 03/26/09
20:05:00

Re: Verify rules

[Mike Wright]

Scott Miller wrote:
> Thanks for the suggestions - I now have the following, combining two replies
> I received.  I will implement this afternoon and see what happens.  I am
> also using Webmin to moidify the /etc/sysconfig/iptables file.  If anyone
> sees anything wrong - please let me know.  My goal is to lock down
> everything except for the mentioned ports.  Thanks for your help.
> 
> *mangle
> :PREROUTING ACCEPT [6:948]
> :INPUT ACCEPT [6:948]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [7:3269]
> :POSTROUTING ACCEPT [7:3269]
> COMMIT
> *nat
> :OUTPUT ACCEPT [0:0]
> :PREROUTING ACCEPT [0:0]
> :POSTROUTING ACCEPT [0:0]
> COMMIT
> *filter
> :FORWARD ACCEPT [0:0]
> :INPUT ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> # MODIFIED APRIL 27 2009 11:01AM
> # TALKING TO OURSLEVES IS ALLOWED
> -A INPUT -p icmp -m icmp --icmp-type any -j ACCEPT
> -A INPUT -i lo -j ACCEPT
> # ALLOW THE FOLLOWING TCP PROTOCOLS HTTP, SSH, DNS, WEBMIN, SMTP, POP3,
> IMAP, RSYNC-TCP
> -A INPUT -p tcp -m multiport -m state --state NEW,ESTABLISHED -j ACCEPT
> --dports 22,25,53,80,110,873,993,10000
> # ALLOW THE FOLLOWING UDP PROTOCOLS TIME, RSYNC-UDP
> -A INPUT -p UDP -m multiport -m state --state NEW,ESTABLISHED -j ACCEPT
> --dports 123,873

if you're going to serve dns you must open port 53 to udp

> # DENY ALL OTHERS ETH0
> -A INPUT -i eth0 -j DROP
> # DENY ALL OTHERS ETH0:1
> -A INPUT -i eth0:1 -j DROP

iptables won't accept an alias.  Besides, the previous rule already 
covers the physical device.  if you set the INPUT chain's default policy 
to DROP you don't need either of the above rules.

also consider that you are not allowing RELATED traffic.  for some 
services that is a deal-breaker.

some additional notes:

some outsiders use the ident port (113) to probe for valid users; if you 
don't reset those you could see 30 second delays waiting for the ident 
to fail.  i seem to remember that it impacted mail severely.  by 
resetting those you save time and they get no revealing information out 
of you.

you may also want to rate limit the number of attempts from the same IP 
to connect to SSH or you WILL get hammered.  If you search the archives 
I think *Joanne Dow* posted an example of how to do so.

> COMMIT

Here is a version that may do what you want:

*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type any -j ACCEPT
-A INPUT -p tcp -m multiport --dports 22,25,53,80,110,873,993,10000 -m 
state --state NEW -j ACCEPT
-A INPUT -p udp -m multiport --dports 53,123,873 -m state --state NEW -j 
ACCEPT
-A INPUT -p tcp --dport 113 -j REJECT --reject-with tcp-reset
COMMIT

Re: Verify rules

[Mike Wright]

Mike Wright wrote:
> Scott Miller wrote:
>> Thanks for the suggestions - I now have the following, combining two 
>> replies
>> I received.

> you may also want to rate limit the number of attempts from the same IP 
> to connect to SSH or you WILL get hammered.  If you search the archives 
> I think *Joanne Dow* posted an example of how to do so.

oops! *Joanne Dow* posted an example of how to do so on the fedora-list.

RE: Verify rules

[Scott Miller]

I tried the following as suggested (removing 53 as this is not a dns
server):

*mangle
:PREROUTING ACCEPT [6:948]
:INPUT ACCEPT [6:948]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [7:3269]
:POSTROUTING ACCEPT [7:3269]
COMMIT
*nat
:OUTPUT ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -A INPUT -i lo -j ACCEPT -A
INPUT -p icmp -m icmp --icmp-type any -j ACCEPT -A INPUT -p tcp -m multiport
--dports 22,25,80,110,873,993,10000 -m state --state NEW -j ACCEPT -A INPUT
-p udp -m multiport --dports 123,873 -m state --state NEW -j ACCEPT -A INPUT
-p tcp --dport 113 -j REJECT --reject-with tcp-reset COMMIT

However - this seemed to completely lock down the server - I could not
access it via port 1000 or http 80, and it would not accept mail for
delivery (smtp) - not exactly sure what happened.  I had to physically go to
the server, and do a "service iptables stop" to regain access and allow
mail.

I'll do some searching for Jane Dow's example, and read again the netfilter
how-to's and see what I can come up with.

Thanks,
Scott Miller





-----Original Message-----
From: netfilter-owner@vger.kernel.org
[mailto:netfilter-owner@vger.kernel.org] On Behalf Of Mike Wright
Sent: Friday, March 27, 2009 12:59 PM
To: Mike Wright
Cc: netfilter@vger.kernel.org
Subject: Re: Verify rules

Mike Wright wrote:
> Scott Miller wrote:
>> Thanks for the suggestions - I now have the following, combining two 
>> replies
>> I received.

> you may also want to rate limit the number of attempts from the same IP 
> to connect to SSH or you WILL get hammered.  If you search the archives 
> I think *Joanne Dow* posted an example of how to do so.

oops! *Joanne Dow* posted an example of how to do so on the fedora-list.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.0.238 / Virus Database: 270.11.28/2022 - Release Date: 03/27/09
07:13:00

Re: Verify rules

[Mike Wright]

Mike Wright wrote:
 > Scott Miller wrote:
 >> Thanks for the suggestions
 >
 > *filter
 > :INPUT DROP [0:0]
 > :FORWARD ACCEPT [0:0]
 > :OUTPUT ACCEPT [0:0]
 > -A INPUT -m state --state ESTABLISHED,RELATED
                                                  ^^^^^^^^
Sorry, it's been a long week.  The above line should read:

 > -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

 > -A INPUT -i lo -j ACCEPT
 > -A INPUT -p icmp -m icmp --icmp-type any -j ACCEPT
 > -A INPUT -p tcp -m multiport --dports 22,25,53,80,110,873,993,10000 -m
 > state --state NEW -j ACCEPT
 > -A INPUT -p udp -m multiport --dports 53,123,873 -m state --state NEW -j
 > ACCEPT
 > -A INPUT -p tcp --dport 113 -j REJECT --reject-with tcp-reset
 > COMMIT

RE: Verify rules

[Scott Miller]

That was it - works perfectly.  Now I have a base-line and can start
tweeking and logging from there.  I will do as others have suggested, and
either only allow SSH from one IP address or range, OR use the pubkey
suggestion.

Thanks!
Scott Miller

-----Original Message-----
From: netfilter-owner@vger.kernel.org
[mailto:netfilter-owner@vger.kernel.org] On Behalf Of Mike Wright
Sent: Friday, March 27, 2009 1:55 PM
To: Scott Miller
Cc: netfilter@vger.kernel.org
Subject: Re: Verify rules

Mike Wright wrote:
 > Scott Miller wrote:
 >> Thanks for the suggestions
 >
 > *filter
 > :INPUT DROP [0:0]
 > :FORWARD ACCEPT [0:0]
 > :OUTPUT ACCEPT [0:0]
 > -A INPUT -m state --state ESTABLISHED,RELATED
                                                  ^^^^^^^^
Sorry, it's been a long week.  The above line should read:

 > -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

 > -A INPUT -i lo -j ACCEPT
 > -A INPUT -p icmp -m icmp --icmp-type any -j ACCEPT
 > -A INPUT -p tcp -m multiport --dports 22,25,53,80,110,873,993,10000 -m
 > state --state NEW -j ACCEPT
 > -A INPUT -p udp -m multiport --dports 53,123,873 -m state --state NEW -j
 > ACCEPT
 > -A INPUT -p tcp --dport 113 -j REJECT --reject-with tcp-reset
 > COMMIT


--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.0.238 / Virus Database: 270.11.28/2022 - Release Date: 03/27/09
07:13:00

Re: Verify rules

[Mart Frauenlob]

netfilter-owner@vger.kernel.org wrote:
> That was it - works perfectly.  Now I have a base-line and can start
> tweeking and logging from there.  I will do as others have suggested, and
> either only allow SSH from one IP address or range, OR use the pubkey
> suggestion.
>
>
>  > -A INPUT -p icmp -m icmp --icmp-type any -j ACCEPT
>   

Also think of maybe not allowing all icmp types. Some you might not 
want, as redirects for example.
suggestion:

iptables -N icmp_input
-A icmp_input -p icmp --icmp-type pong -m state --state ESTABLISHED -j 
ACCEPT
-A icmp_input -p icmp --icmp-type destination-unreachable -m state 
--state RELATED -j ACCEPT

... also problem describing, but should not break anything if not 
allowed (AFAIK...): source-quench, time-exceeded, parameter-problem - 
accept in related state also...
-A icmp_input -p icmp -j DROP
-A INPUT -p icmp -j icmp_input

greets

Mart

Re: Verify rules

[Mike Wright]

Mike Wright wrote:
> Scott Miller wrote:
>> Thanks for the suggestions
>
> *filter
> :INPUT DROP [0:0]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> -A INPUT -m state --state ESTABLISHED,RELATED
                                                  ^^^^^^^^
Sorry, it's been a long week.  The above line should read:

> -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

> -A INPUT -i lo -j ACCEPT
> -A INPUT -p icmp -m icmp --icmp-type any -j ACCEPT
> -A INPUT -p tcp -m multiport --dports 22,25,53,80,110,873,993,10000 -m
> state --state NEW -j ACCEPT
> -A INPUT -p udp -m multiport --dports 53,123,873 -m state --state NEW -j
> ACCEPT
> -A INPUT -p tcp --dport 113 -j REJECT --reject-with tcp-reset
> COMMIT

RE: Verify rules

[Rob Sterenborg]

> you may also want to rate limit the number of attempts from the
> same IP to connect to SSH or you WILL get hammered.  If you
> search the archives I think *Joanne Dow* posted an example of
> how to do so.

If you don't need everyone to be able to reach the ssh port, you can lock the source IP's that must be able to reach the SSH port down to only the ones that should be able.
Also/or, you could create 2 sshd_config's (with of course 2 separate sshd's on the inet and lan/dmz interfaces) and configure the inet sshd to only accept a pubkey instead of password authentication. It isn't too hard to do and you're rid of password guessing attacks.


Grts,
Rob