Find the answer to your Linux question:
Results 1 to 9 of 9
Hi. I am working on setting up a virtual for patch testing and in addition application testing. I have a PowerEdge 2950 server running Ubuntu LTS 6.10 with VMWare 1.x ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Jul 2009
    Posts
    6

    iptables and vmware


    Hi.

    I am working on setting up a virtual for patch testing and in addition application testing. I have a PowerEdge 2950 server running Ubuntu LTS 6.10 with VMWare 1.x on it. Inside that I have 2 windows servers and 2 XP workstations - we use different subnets for the virtual machines and our production network.

    Simple enough but here's where the hard part comes: Preventing those windows boxes from 'talking' to our production windows boxes. I am using iptables to do the usual DROP and some nat for PRE and POST routing.

    I have found that I need to use POST routing to mask the subnet of the virtual servers as any traffic meant for the Internet is flagged by our firewall as spoofing.

    I use PRE routing to connect to Remote Desktop on one of the XP workstations. I know I could use the VMware console but that's really just screen scraping technology and quite slow compared to the RDP.

    So I would like know if someone out there is interested in reviewing my iptables rules just for a sanity check.

    Any takers? Thanks in advance.

    --jj

  2. #2
    Linux Guru Lazydog's Avatar
    Join Date
    Jun 2004
    Location
    The Keystone State
    Posts
    2,677
    How about posting them and then other will chime in.

    Regards
    Robert

    Linux
    The adventure of a life time.

    Linux User #296285
    Get Counted

  3. #3
    Just Joined!
    Join Date
    Jul 2009
    Posts
    6
    Right then - here are the rules i have been working at...

    *nat
    :PREROUTING ACCEPT [15244:1542996]
    :POSTROUTING ACCEPT [94:7126]
    :OUTPUT ACCEPT [448:32867]
    -A PREROUTING -s 192.168.0.x -i eth0 -j DNAT --to-destination 192.168.5.xxx
    -A POSTROUTING -s 192.168.5.0/255.255.255.0 -o vmnet1 -j SNAT --to-source 192.168.0.xx

    *filter
    :INPUT DROP [15255:1547088]
    :FORWARD DROP [0:0]
    :OUTPUT DROP [27:2472]
    -A INPUT -d 192.168.0.xx -p icmp -m state --state NEW,RELATED,ESTABLISHED -m icmp --icmp-type 8 -j ACCEPT
    -A INPUT -d 192.168.0.xx -p icmp -m state --state NEW,RELATED,ESTABLISHED -m icmp --icmp-type 0 -j ACCEPT
    -A INPUT -d 192.168.0.xx -p udp -m state --state NEW,RELATED,ESTABLISHED -m udp --sport 53 -j ACCEPT
    -A INPUT -s 192.168.0.xxx -d 192.168.0.xx -p tcp -m tcp --dport 22 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
    -A INPUT -d 192.168.0.xx -p tcp -m multiport --sports 20,21,80 -m state --state RELATED,ESTABLISHED -j ACCEPT
    -A INPUT -s 192.168.0.xxx -d 192.168.0.xx -i eth0 -p tcp -m tcp --dport 902 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
    -A FORWARD -d 192.168.0.xx -i vmnet1 -o eth0 -p tcp -m state --state NEW,RELATED,ESTABLISHED -m tcp --dport 53 -j ACCEPT
    -A FORWARD -s 192.168.0.xx -i eth0 -o vmnet1 -p tcp -m state --state NEW,RELATED,ESTABLISHED -m tcp --sport 53 -j ACCEPT
    -A FORWARD -d 192.168.0.xx -i vmnet1 -o eth0 -p tcp -m state --state NEW,RELATED,ESTABLISHED -m multiport --dports 20,21,80,443 -j ACCEPT
    -A FORWARD -s 192.168.0.xx -i eth0 -o vmnet1 -p tcp -m state --state NEW,RELATED,ESTABLISHED -m multiport --sports 20,21,80,443 -j ACCEPT
    -A FORWARD -i eth0 -o vmnet1 -p tcp -m iprange --src-range 192.168.0.xxx-192.168.0.xxx -m tcp --dport 3389 -j ACCEPT
    -A FORWARD -i vmnet1 -o eth0 -p tcp -m iprange --dst-range 192.168.0.xxx-192.168.0.xxx -m tcp --sport 3389 -j ACCEPT
    -A OUTPUT -s 192.168.0.xx -p icmp -m state --state NEW,RELATED,ESTABLISHED -m icmp --icmp-type 8 -j ACCEPT
    -A OUTPUT -s 192.168.0.xx -p icmp -m state --state NEW,RELATED,ESTABLISHED -m icmp --icmp-type 0 -j ACCEPT
    -A OUTPUT -s 192.168.0.xx -p tcp -m state --state NEW,RELATED,ESTABLISHED -m tcp --sport 22 -j ACCEPT
    -A OUTPUT -s 192.168.0.xx -p udp -m udp --dport 53 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
    -A OUTPUT -s 192.168.0.x -p tcp -m multiport --dports 20,21,80 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
    -A OUTPUT -s 192.168.0.xx -d 192.168.0.xxx -o eth0 -p tcp -m tcp --sport 902 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

  4. #4
    Just Joined!
    Join Date
    Jul 2009
    Posts
    6
    Are there any iptables masters out there?

    --jj

  5. #5
    Just Joined!
    Join Date
    Jul 2009
    Posts
    6

    update

    Well I have been a bit more successful in reaching my goals.

    For those that want to know, here are the rules I have been using:

    Chain INPUT (policy DROP)
    target prot opt source destination
    ACCEPT icmp -- 0.0.0.0/0 192.168.0.xx state NEW,RELATED,ESTABLISHED icmp type 8
    ACCEPT icmp -- 0.0.0.0/0 192.168.0.xx state NEW,RELATED,ESTABLISHED icmp type 0
    ACCEPT udp -- 0.0.0.0/0 192.168.0.xx state NEW,RELATED,ESTABLISHED udp spt:53
    ACCEPT tcp -- 192.168.0.xxx 192.168.0.xx tcp dpt:22 state NEW,RELATED,ESTABLISHED
    ACCEPT tcp -- 0.0.0.0/0 192.168.0.xx multiport sports 20,21,80 state RELATED,ESTABLISHED
    ACCEPT tcp -- 192.168.0.xxx 192.168.0.xx tcp dpt:902 state NEW,RELATED,ESTABLISHED

    Chain FORWARD (policy DROP)
    target prot opt source destination
    ACCEPT udp -- 192.168.5.0/24 0.0.0.0/0 udp dpt:53 state NEW,RELATED,ESTABLISHED
    ACCEPT udp -- 0.0.0.0/0 192.168.5.0/24 udp spt:53 state RELATED,ESTABLISHED
    ACCEPT tcp -- 192.168.5.0/24 0.0.0.0/0 multiport dports 20,21,80,443 state NEW,RELATED,ESTABLISHED
    ACCEPT tcp -- 0.0.0.0/0 192.168.5.0/24 multiport sports 20,21,80,443 state RELATED,ESTABLISHED
    ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 source IP range 192.168.0.xxx-192.168.0.xxx tcp dpt:3389
    ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 destination IP range 192.168.0.xxx-192.168.0.xxx tcp spt:3389

    Chain OUTPUT (policy DROP)
    target prot opt source destination
    ACCEPT icmp -- 192.168.0.xx 0.0.0.0/0 state NEW,RELATED,ESTABLISHED icmp type 8
    ACCEPT icmp -- 192.168.0.xx 0.0.0.0/0 state NEW,RELATED,ESTABLISHED icmp type 0
    ACCEPT tcp -- 192.168.0.xx 0.0.0.0/0 state NEW,RELATED,ESTABLISHED tcp spt:22
    ACCEPT udp -- 192.168.0.xx 0.0.0.0/0 udp dpt:53 state NEW,RELATED,ESTABLISHED
    ACCEPT tcp -- 192.168.0.xx 0.0.0.0/0 multiport dports 20,21,80 state NEW,RELATED,ESTABLISHED
    ACCEPT tcp -- 192.168.0.xx 192.168.0.xxx tcp spt:902 state NEW,RELATED,ESTABLISHED


    Chain PREROUTING (policy ACCEPT)
    target prot opt source destination
    DNAT tcp -- 192.168.0.xxx 0.0.0.0/0 tcp dpt:3389 to:192.168.5.xxx:3389

    Chain POSTROUTING (policy ACCEPT)
    target prot opt source destination
    SNAT all -- 192.168.5.0/24 0.0.0.0/0 to:192.168.0.xx

    As I say, it works though I'd rather be sure. I also used nmap to scan it which only found the VMware Console and SSH ports to be open. When I used to Remote Desktop to connect to one of the XP stations, nmap found 3389 as indeed it should have.

    A lot of writing on whiteboards and planning it out for sure. Hopefully someone is interested in improving this set of rules...

    --jj

  6. #6
    Linux Guru Lazydog's Avatar
    Join Date
    Jun 2004
    Location
    The Keystone State
    Posts
    2,677
    I am at work presently and don't have the time to pick through your rules but I will tell you this. At the op of all your chains INPUT OUTPUT FORWARD ect., you should place the following rule;

    Code:
    -A chain -m state --state ESTABLISHED,RELATED -j ACCEPT
    Then change all the NEW,ESTABLISHED,RELATED to NEW

    This will stop the firewall from having to read all the rules until one is matched for Established and Related connection. Some will say this is not needed as you will never see the difference but I like the idea that there are less cpu cycles going to reading firewall rules that could be doing something else.

    Regards
    Robert

    Linux
    The adventure of a life time.

    Linux User #296285
    Get Counted

  7. #7
    Just Joined!
    Join Date
    Jul 2009
    Posts
    6
    Well I added the RELATED,ESTABLISHED as suggested and everything appears to work quite well. Then I added the NEW as suggested and again, everything appears to be working quite well. I also added logging so I can 'debug'. I am a little skeptical about the RELATED,ESTABLISHED simply because of Windows. I was wondering, even if the policies are set to DROP, if I want to make sure the firewall is indeed dropping NetBIOS and AD related packets should I specifically create some rules under FORWARD to monitor that?

    What I mean is: Should I make rules under the FORWARD filter in spite of the default policy being set to DROP and enable logging for any Windows AD/SMB packets? If I do then I would need to block the following:

    RPC endpoint mapper 135/tcp, 135/udp

    NetBIOS 137/tcp, 137/udp

    NetBIOS datagram service 138/udp

    NetBIOS session service 139/tcp

    Microsoft-DS 445/tcp, 445/udp

    LDAP 389/tcp

    LDAP ping 389/udp

    LDAP over SSL 636/tcp

    Global catalog LDAP 3268/tcp

    Global catalog LDAP over SSL 3269/tcp

    Kerberos 88/tcp, 88/udp

    Thanks for any and all suggestions to this challenge.

    --jj

  8. #8
    Linux Guru Lazydog's Avatar
    Join Date
    Jun 2004
    Location
    The Keystone State
    Posts
    2,677
    Sure you could do this if you want. Just remember your log files will fill fast with Windows on the network.

    Take a look at this for how to setup multiport filer

    Regards
    Robert

    Linux
    The adventure of a life time.

    Linux User #296285
    Get Counted

  9. #9
    Just Joined!
    Join Date
    Jul 2009
    Posts
    6
    Quote Originally Posted by Lazydog View Post
    Sure you could do this if you want. Just remember your log files will fill fast with Windows on the network.

    Take a look at this for how to setup multiport filter
    I didn't even consider that multiport matching for 'debugging'. That's great stuff. My next step after that is making sure there is no NetBIOS broadcasts which is a bit of work - you have to publish your shares in AD which makes them searchable.

    Thanks for the tip LD - I'll let you know how it works.

    --jj

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •