Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 3 subscribers
  • Views 9621 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Subnet bleed

Coder68
Firewall rule look like this:

Trusted --> Web Surfing --> Any --> Allow 

Hacklab --> Any service --> Any --> Allow 

I built this new box in phases, late at night when I was tired. No excuse, but this is a good lesson for all. Be careful! 

Thank you teched

------

I can scan (Nmap) my trusted network from my Hacklab network. 

I thought that there was automatic isolation between separate NICs/subnets unless explicitly allowed. 

What have I forgotten?? [:O] (To follow my own instructions, and to look at the UTM I built MANY years ago...which was done correctly !) [:D]

------------------------------FOLLOW UP-------------------------------------------
teched caught my mistake and sent a PM minutes after I posted this. I Could have deleted the post, and hide my embarrassment, but I think this is a good lesson so I left it up.

So what happened here? 

I was reading my firewall rules, incorrectly, like this:

Hacklab--> Any --> ANY Internet address. 

Looking at my older UTM (This morning), I was using Internet and not ANY. 

This new UTM is still in test mode, (Behind my old UTM) so there was no real external risk here, but this could have been a big issue had I not tested. I had created a document on how to build my new UTM, using my old UTM as a template, but I did not follow my own document on firewall rules!

This is another reason why I like to test all my builds before putting into production, even when I do follow my own instructions. Testing is what I was doing last night. I had taken a trusted Linux PC and put it on my still virgin hacklab network and started to verify isolation. It is a good thing that I did as this is also my malware lab! [:O]

I hope this prevents someone from making this same error!

C68


This thread was automatically locked due to age.
Parents
  • 0
    CR, the only effect of Rule #6 is to have it mentioned instead of a default drop in the firewall log.  As you surmised, all traffic not explicitly allowed is dropped.

    If you refer to #2 in Rulz, you will understand that allowing the Guineapig network to use Web Filtering will allow browsing to things in Squirrel in spite of your explicit Block rule.

    Cheers - Bob
  • 0 in reply to BAlfson

    Hi all, I'm running into something similar and cannot for the life of me figure out what boneheaded error I've made.

    We've got 5 VLANs on our internal interface, numbered 50, 60, 70, 80, and 90.

    70 and 80 are "special" and are allowed to talk across two RED tunnels (to WESTlan and EASTlan).

    We want one host in 70 (rmhprint) to talk to certain hosts in 80 (rh1, rh2) and we want anything in 80 to talk to anything in 70.  We also want 70 and 80 to be able to pass anything to 50/60/90 but want nothing to be passable in the opposite direction.

    I've set up what I think is appropriate, and everything works except that none of the hosts in 80 can talk to hosts in 70.

  • 0 in reply to pesos

    This is what I see in live log when I try to access a file share on rmhprint (in 70) from rh2 (in 80).  As you can see, it appears to be confusing which host is initiating the traffic (which is SMB on port 445) and it's blocking it.  Any guesses why?

    I also noticed that the live log is listing two different mac addresses for this host - is that because it is a hyper-v host?  We just went through migrating these VMs to a new hyper-v host so I'm wondering if there isn't some kind of weird MAC issue complicating things?

    I've tried rebooting the UTM to no avail...

    Thanks!

Reply
  • 0 in reply to pesos

    This is what I see in live log when I try to access a file share on rmhprint (in 70) from rh2 (in 80).  As you can see, it appears to be confusing which host is initiating the traffic (which is SMB on port 445) and it's blocking it.  Any guesses why?

    I also noticed that the live log is listing two different mac addresses for this host - is that because it is a hyper-v host?  We just went through migrating these VMs to a new hyper-v host so I'm wondering if there isn't some kind of weird MAC issue complicating things?

    I've tried rebooting the UTM to no avail...

    Thanks!

Children
  • 0 in reply to pesos

    That shows that a response to an SMB request was sent by 10.13.70.5 to 10.13.80.12.  Alone among the logs, the Firewall Live Log presents abbreviated information in a format easier to read quickly.  Usually, you can't troubleshoot without looking at the corresponding line from the full Firewall log file.  Please post one line corresponding to the first line above.

    I guess the connection tracker believes the SMB conversation between the two had ended.  Are you sure there's not a network storm in VLAN 70?

    Cheers - Bob

  • 0 in reply to BAlfson

    Thanks Bob, no storm and hardly any traffic at all.  SMB works fine in the other direction.

    Also, I just tested and I CAN successfully connect to UNC shares on 70.5 from the domain controllers in vlan 80.  So I'm unclear as to what's different about rh1/rh2 vs. rdc1/rdc2 that would cause this behavior...  When I look at my ruleset, I just don't see why they would be treated any differently...