Can someone give me some clear examples when to use -> or <>?
Is -> inbound traffic?
Is <> inbound and outbound traffic?
Do these rulesets provide the same results?
I tried it but I got different results which perplexed me. Why did I get different results?
What is the difference between those two rulessets?
No.1
alert tcp any 80 <> any 80 (...)
No.2
alert tcp any 80 -> any any (...)
alert tcp any any -> any 80 (...)
The same results/alerts
Related
Suppose I have two ec2 instances on aws ec2_A and ec2_B. I have two Security groups attached to it to sg_A and sg_B respectively. now suppose I have added an inbund rule on sg_B that sg_A can access tcp protocol on port 3456 on ec2_B. But when the handshake will happen:
ec2_A:5547 -> ec2_B:3456 (this is allowed as I have allowd sg_A on sg_B right?)
in return when ec2_B will send response to ec2_A on port 5547 will it accept the response as I have not open the port 5547 in sg_A for ec2_A? If yes then HOW and "WHY SPECIALLY"?
Yes it will accept the response. The reason why is because security groups are stateful. The security group knows that this is a response for a request it has made therefore it is allowed regardless of the inbound rules.
More information on how this is achieved can be found in the official docs here: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html#security-group-connection-tracking
I am using Wireshark to capture TCP communication packets in my experiment (using Mininet Simulation). The experiment involves a client (10.0.0.2) who requests HTTP page from the server (10.0.0.1). The following screenshot shows the capturing number 75 when the client sends HTTP GET and capturing number 89 when the server responds. Between them, I don't know what these packets are. Are they important in terms of TCP communication?
Thank you
depends on what you are analyzing. If you are concerned with the HTTP conversation then right click on one of the http rows and click- follow TCP stream. This lets you see entire http session. If you are having issues with the underlying TCP connection then those in-between rows become important.
I'm trying to capture from a pcap file connections that starts correctly (with 3-way protocol: syn,syn-ack,ack) and ends correctly.
To capture connections that starts correctly I use the following filter:
(tcp.flags.syn == 1) || (tcp.flags.syn==1 && tcp.flags.ack==1)
I don't filter just by ack's because it will filter every single package that contains an ack and isn't useful to me. So I use: SYN or SYN-ACK flags to filter.That's only for starting connections so, how I should filter packages to get also ending packages?
I'm using something like this: (tcp.flags.fin==1) || (tcp.flags.fin==1 && tcp.flags.ack==1)
I don't feel that's correct because I don't know exactly how every connection ends, that depends on implementation? or is always the same?
it is always the same for TCP connection, save for abnormal situations when a peer reset the connection (RST flag). Also, in wireshark you have convenient option: if you right-click a packet a choose "follow TCP stream" it will display only packets belonging to that connection, so you can see how it starts and ends...
I want to develop an application where all traffic from network segment gets mirrored onto a windows station in order to be able to see all tcp-ip request/response data (filtering).
I know that it should be possible using WinPcap to capture all packets but problem in this case would be that I would have to implement all the processing needed to be able to distinguish tcp data streams (e.g. handshaking, closing, retransmissions, reordering, maybe others ?). I need the stream of data because I will be doing application level (e.g. http) filtering.
I wonder if there is a driver/solution somewhere that provides me tcp data stream, solution that could be used on a gateway machine or using port mirroring.
For starters, in WinPCap, you can define something called filter.
That filter filters out all the traffic except the type that you specify, so if you want to capture HTTP traffic only, I'd suggest you make a filter on TCP Port 80 or any other port you're using for HTTP.
Once you've captured these packets, you can check the payload of the TCP, parse the HTTP header and do whatever you wish according to your system's policy.
Check this link if you want to familiarize yourself with how to use WinPCap and how to use filters(in this example they're capturing TCP traffic in general, you should add to their filter "port 80").
Traceroute is an application to trace the path from A to B. (A is your location and B is the server you want to trace). In Windows, you can type tracert. The main algorithm is:
send UDP with TTL = 1
Server A1 received, and return ICMP packet to A because TTL is expired.
--> know first machine between. For example A1.
send UDP with TTL = 2
Server A1 received, and send this UDP to server A2.
Server A2 received, and return ICMP packet to A because TTL is expired
--> know second machine between. In this example is A2.
Do it until to B. we can track down: A -> A1 -> A2 -> ... ->B
Does this algorithm work correctly? Because at different time, an intermediate server can send a message to different server. For example, at first time, UDP message is sent to A1, but at a later time, it can send to another server, for example, B1. So, trace route will not work properly.
Did I misunderstand something?
From the man page :
traceroute tracks the route packets take from an IP network on
their
way to a given host
So if you are trying to find one of the possible paths your packet may take, you'll find a friend in traceroute .
Now because routing tables do not change every minute, the packets that you send will most probably take the same path as traced by traceroute.
Another important point that cannot be missed is the record route option in the IP v4 header.
Once you specify that you want to use this option, every router in the path will add it's ip address to the options in the header. You can read more about it here. The catch being that the destination gets to know about the intermediate hops , not the source.
I see that you missed the role of icmp echo request and reply messages in the description of traceroute. In case this was not intentional , take a look.
Update : You can see the record route option in action by doing a ping -R
ping -R Turns on route recording for the Echo Request packets, and
display the route buffer on returned packets (ignored by many
routers).
The algorithm works properly. Indeed, routing may change due to considerations of different servers along the way, such as server load or availability. Let's say you want to send message from A to B. If the route is not changeable, what will happen if some server on the route is down? If the routing couldn't be adjusted dynamically, that would result in inability to deliver the message to the destination in this example. Here is a different example: let's say you have a server that is used for some heavy computation during the day but it's idle during the night. It's possible to allow it to pass traffic only during the night, so any routing using it will need to be changed at day.
To conclude all this we can definitely say that without dynamic routing the internet couldn't have existed in its' present form.
Addition:
Tracert sends message from A to B. It shows hops along the way. These hops constitute a valid route from A to B at the time of the execution. There is no guarantee that connection between 2 adjacent points along the way is valid after the hop has been completed. The only thing guaranteed is that for each hop there was a link between it's 2 endpoints when the message sent by tracert passed there.